Cleanup the new ErrorHandler component #32605

nicolas-grekas · 2019-07-18T17:22:05Z

Right now, this component is a copy/paste from Debug, but it can and should diverge now.

Here are things that should be done, to be confirmed by trying:

remove ExceptionHandler: we don't need anymore to recover from failed userland rendering ([ErrorHandler] Decouple from ErrorRenderer component #32637)
remove the FatalErrorException class and namespace: this doesn't apply anymore since PHP7, right? ([ErrorHandler] Rework fatal errors #33053)
add type declarations ([ErrorHandler] Added type declarations where possible #32812)
support Throwable directly ([ErrorHandler] Forward \Throwable #33038)
decouple from the ErrorRenderer component ([ErrorHandler] Decouple from ErrorRenderer component #32637)

/cc @fancyweb @yceruto as you like this part of the code base :)

yceruto · 2019-07-18T17:39:20Z

Yes, I'll take a look soon 👍

…yceruto) This PR was squashed before being merged into the 4.4 branch (closes #32637). Discussion ---------- [ErrorHandler] Decouple from ErrorRenderer component | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | part of #32605 | License | MIT | Doc PR | - built on top of #32636 (See 2nd commit only) Commits ------- 8f13fc0 [ErrorHandler] Decouple from ErrorRenderer component

fancyweb · 2019-07-31T13:14:02Z

remove the FatalErrorException class and namespace: this doesn't apply anymore since PHP7, right?

@yceruto Looking at this.

@nicolas-grekas I have several questions.

Al of our own fatal error handlers are indeed useless since PHP 7. However, the ErrorHandler::getFatalErrorHandlers is an extension point that allow userland to define their own handlers. Removing it is removing a feature. So should we just remove our own useless handlers and keep the behavior or remove our handlers + deprecate the method to remove it later with all the associated behavior or just remove everything since it's a new component?

Also, should we clean the Debug component as well or we just let it die with unneeded classes?

Tobion · 2019-08-01T11:30:06Z

Debug component is deprecated. No point in changing that.

vudaltsov · 2019-08-04T23:14:33Z

It seems that E_STRICT can be dropped, because it's not used anymore in PHP 7. See https://wiki.php.net/rfc/reclassify_e_strict

fancyweb · 2019-08-05T16:21:45Z

For information, I'm working on handling \Throwable directly in ErrorHandler::handleException() too.

@vudaltsov Are you able to take care of the E_STRICT removal?

vudaltsov · 2019-08-05T17:03:48Z

@fancyweb , yes, I am. Will look at it tomorrow.

derrabus · 2019-08-08T14:56:11Z

I like where this is going. May I reopen #26514?

fancyweb · 2019-09-06T09:08:13Z

About the E_STRICT removal: I think we need to keep it. The constant was not removed from PHP so users can still trigger with this level.

vudaltsov · 2019-09-06T09:35:00Z

@fancyweb , that's a nice point, fully agree. But then we can add a deprecation there, so that devs stop triggering E_STRICT.

Earlier I promised to help with this. But I got a new job and don't have much time at the moment.

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Forward \Throwable | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #32605 | License | MIT | Doc PR | - The goal of this PR is that `ErrorHandler::handleException()` handles `\Throwable` directly and forwards it without altering it. Commits ------- 62483ed [ErrorHandler] Forward \Throwable

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Forward \Throwable | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#32605 | License | MIT | Doc PR | - The goal of this PR is that `ErrorHandler::handleException()` handles `\Throwable` directly and forwards it without altering it. Commits ------- 62483ed305 [ErrorHandler] Forward \Throwable

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Forward \Throwable | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#32605 | License | MIT | Doc PR | - The goal of this PR is that `ErrorHandler::handleException()` handles `\Throwable` directly and forwards it without altering it. Commits ------- 62483ed [ErrorHandler] Forward \Throwable

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Rework fatal errors | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #32605 | License | MIT | Doc PR | - Built on top of #33038 so review only the second commit : d5c3f7e The goals of this PR is to replace current "fatal error handlers" with "error enhancers" since all our current fatal error handlers works on \Error since PHP7. That means we won't use the FatalErrorException anymore, so we will be able to remove it (once we don't need it in the rest of the codebase). The final goal btw is to handle \Throwable everywhere in the code so we can remove FatalThrowableError & FatalErrorException classes. Commits ------- aaa0cdf [ErrorHandler] Rework fatal error handlers

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Rework fatal errors | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#32605 | License | MIT | Doc PR | - Built on top of symfony/symfony#33038 so review only the second commit : symfony/symfony@d5c3f7e The goals of this PR is to replace current "fatal error handlers" with "error enhancers" since all our current fatal error handlers works on \Error since PHP7. That means we won't use the FatalErrorException anymore, so we will be able to remove it (once we don't need it in the rest of the codebase). The final goal btw is to handle \Throwable everywhere in the code so we can remove FatalThrowableError & FatalErrorException classes. Commits ------- aaa0cdf523 [ErrorHandler] Rework fatal error handlers

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Rework fatal errors | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#32605 | License | MIT | Doc PR | - Built on top of symfony/symfony#33038 so review only the second commit : symfony/symfony@d5c3f7e The goals of this PR is to replace current "fatal error handlers" with "error enhancers" since all our current fatal error handlers works on \Error since PHP7. That means we won't use the FatalErrorException anymore, so we will be able to remove it (once we don't need it in the rest of the codebase). The final goal btw is to handle \Throwable everywhere in the code so we can remove FatalThrowableError & FatalErrorException classes. Commits ------- aaa0cdf [ErrorHandler] Rework fatal error handlers

This PR was merged into the 4.4 branch. Discussion ---------- [ErrorHandler] Rework fatal errors | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#32605 | License | MIT | Doc PR | - Built on top of symfony/symfony#33038 so review only the second commit : symfony/symfony@d5c3f7e The goals of this PR is to replace current "fatal error handlers" with "error enhancers" since all our current fatal error handlers works on \Error since PHP7. That means we won't use the FatalErrorException anymore, so we will be able to remove it (once we don't need it in the rest of the codebase). The final goal btw is to handle \Throwable everywhere in the code so we can remove FatalThrowableError & FatalErrorException classes. Commits ------- aaa0cdf523 [ErrorHandler] Rework fatal error handlers

yceruto · 2019-10-15T21:17:39Z

All tasks completed so far, thank you to everyone involved!

… 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

yceruto added the ErrorHandler label Jul 18, 2019

This was referenced Jul 20, 2019

[ErrorHandler][HttpKernel] Removed ExceptionHandler class, use ErrorHandler instead #32636

Closed

[ErrorHandler] Decouple from ErrorRenderer component #32637

Merged

yceruto added the Enhancement label Jul 30, 2019

yceruto added this to the next milestone Jul 30, 2019

This was referenced Aug 8, 2019

[ErrorHandler] Forward \Throwable #33038

Merged

[ErrorHandler] Rework fatal errors #33053

Merged

fancyweb mentioned this issue Aug 8, 2019

Deprecate things that prevent \Throwable from bubbling down #33065

Merged

Tobion mentioned this issue Sep 16, 2019

[Messenger] Message retried in failure transport dropped on exception #32719

Closed

yceruto closed this as completed Oct 15, 2019

nicolas-grekas modified the milestones: next, 4.4 Oct 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cleanup the new ErrorHandler component #32605

Cleanup the new ErrorHandler component #32605

nicolas-grekas commented Jul 18, 2019 •

edited by Tobion

Loading

yceruto commented Jul 18, 2019

fancyweb commented Jul 31, 2019

Tobion commented Aug 1, 2019

vudaltsov commented Aug 4, 2019

fancyweb commented Aug 5, 2019

vudaltsov commented Aug 5, 2019

derrabus commented Aug 8, 2019

fancyweb commented Sep 6, 2019

vudaltsov commented Sep 6, 2019

yceruto commented Oct 15, 2019

Cleanup the new ErrorHandler component #32605

Cleanup the new ErrorHandler component #32605

Comments

nicolas-grekas commented Jul 18, 2019 • edited by Tobion Loading

yceruto commented Jul 18, 2019

fancyweb commented Jul 31, 2019

Tobion commented Aug 1, 2019

vudaltsov commented Aug 4, 2019

fancyweb commented Aug 5, 2019

vudaltsov commented Aug 5, 2019

derrabus commented Aug 8, 2019

fancyweb commented Sep 6, 2019

vudaltsov commented Sep 6, 2019

yceruto commented Oct 15, 2019

nicolas-grekas commented Jul 18, 2019 •

edited by Tobion

Loading