-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Deprecate things that prevent \Throwable from bubbling down #33065
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
9b979ef
to
584f4d6
Compare
src/Symfony/Component/HttpKernel/Event/GetResponseForExceptionEvent.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpKernel/Event/GetResponseForExceptionEvent.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpKernel/EventListener/ExceptionListener.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpKernel/Event/GetResponseForExceptionEvent.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpKernel/EventListener/ExceptionListener.php
Outdated
Show resolved
Hide resolved
2d97e89
to
686a041
Compare
3c4d592
to
ee0b458
Compare
ee0b458
to
f179713
Compare
The other PRs have been merged. We should try to finish this one. |
251c11b
to
5146ad0
Compare
837615b
to
2dbeb57
Compare
Following this logic, we should also handle exceptions and errors differently in the ErrorRenderer and we should not change typehints to throwable but actually have different methods for each. So all of these deprecations are not needed. |
Then we can go back to what Thomas originally implemented: Just introduce a new method on ExceptionEvent: |
Not really required, because ErrorHandler is the last resort logic: it's a generic enough place who's purpose is to report what happened, no matter what.
Yes, that's what I've been wondering also. So, case by case: on Application, we're on a generic enough logic that only reports back what happened - similar to ErrorHandler. On DataCollector, we collect what happened without disrupting the code flow. On listeners, that's not the same story at all - there, any userland logic can mess up with
That wouldn't be nice in terms of naming, neither in term of FC/BC (another boring thing forced on users) + skips my arguments about the necessity to split between Error and Exception :) |
I'm removing myself from this Throwable topic as I've already spend alot of time reviewing this. My opinion is that wrapping Error into an ErrorException just for it to comply with the ExceptionEvent typehints is nonesense and a legacy behavior. And this is what we originally wanted to fix. You argue that error and exception should be handled differently but yet the current behavior and proposed behavior is pretending an error to be an exception. So I don't know anymore where this is going. |
21e8bc6
to
8e67186
Compare
2bdbda7
to
879c634
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a nice first step, thanks for working on this complex topic.
src/Symfony/Component/HttpKernel/EventListener/ExceptionListener.php
Outdated
Show resolved
Hide resolved
d62a2fc
to
139f4b4
Compare
139f4b4
to
abef506
Compare
Thank you @fancyweb. |
… down (fancyweb) This PR was merged into the 4.4 branch. Discussion ---------- Deprecate things that prevent \Throwable from bubbling down | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes (todo update CHANGELOGS & UPGRADES) | Tests pass? | yes | Fixed tickets | #32605 | License | MIT | Doc PR | - ~The goal of this PR is to allow `\Throwable` forwarded from the`ErrorHandler::handleException()` method (cf #33038) to bubble down in our code base without having to convert them into exceptions.~ ~WIP because I'm blocked by 2 things caused by `GetResponseForExceptionEvent::getThrowable()` returning a `\Throwable` instead of an `\Exception`.~ ~1. This `\Throwable` end up in `DataCollectorInterface::collect()` (cf `ProfilerListener`). So that looks impossible to support in 4.4. What can we do?~ ~2. The second blocker is `ExceptionListener::duplicateRequest()`. We are not gonna rename this method to support `\Throwable` I guess. What can we do?~ Since there are blockers to do it in 4.4, let's prepare for the future and deprecate the things that block us. Commits ------- abef506 Deprecate things that prevent \Throwable from bubbling down
now merged into master |
…r (fancyweb) This PR was merged into the 5.0-dev branch. Discussion ---------- Remove \Throwable bubbling down support deprecation layer | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - Remove deprecation layer of #33065 Commits ------- ffcfdb4 Remove \Throwable support deprecation layer
The goal of this PR is to allow\Throwable
forwarded from theErrorHandler::handleException()
method (cf #33038) to bubble down in our code base without having to convert them into exceptions.WIP because I'm blocked by 2 things caused byGetResponseForExceptionEvent::getThrowable()
returning a\Throwable
instead of an\Exception
.1. This\Throwable
end up inDataCollectorInterface::collect()
(cfProfilerListener
). So that looks impossible to support in 4.4. What can we do?2. The second blocker isExceptionListener::duplicateRequest()
. We are not gonna rename this method to support\Throwable
I guess. What can we do?Since there are blockers to do it in 4.4, let's prepare for the future and deprecate the things that block us.