Problem/Motivation
Note that by now,
\Drupal\Core\EventSubscriber\DefaultExceptionSubscriberreally always does the same thing: it always ends up callingonHtml()for fatal errors. In other words: it's finally living up to its description:/** * Last-chance handler for exceptions. * * This handler will catch any exceptions not caught elsewhere and report * them as an error page. */So I think we should rename the class (to
FatalErrorExceptionSubscriber) and simplify the logic (get rid of the currentonException()and make the currentonHtml()the newonException(), then get rid of everything else).But that… is for another issue.
This is that issue.
Another consequence is that this "last chance" exception handler also then treats all unhandled exceptions the same way: it will print a backtrace if verbose error logging is enabled for both HTML requests and REST requests, and … anything else. Currently, it only does that for HTML requests.
Proposed resolution
- always do the same, regardless of format
- renames
DefaultExceptionSubscribertoFinalExceptionSubscriber - renames the service from
exception.defaulttoexception.final - adds helpful documentation explaining how this exception subscriber compares to the others
Remaining tasks
None.
User interface changes
For non-HTML requests with a fatal PHP error or another kind of unhandled exception: a backtrace if verbose error logging is enabled.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 2853300-19.patch | 14.38 KB | wim leers |
Comments
Comment #2
wim leersComment #3
wim leersThis is a start. This should be further simplified step-by-step, to prove that it works.
But for that to make sense (i.e. for tests to be able to pass), we need #2825347: 'Accept' header still is used for determining response format of error responses, ?_format= has no effect AND serialization module's exception subscriber does not support status code 500 error responses to land first.
Comment #4
wim leers#2825347: 'Accept' header still is used for determining response format of error responses, ?_format= has no effect AND serialization module's exception subscriber does not support status code 500 error responses landed, this is now unblocked!
Comment #6
dawehnerNice simplification!
Comment #7
xjmThis patch has one less hunk than I would expect given the issue title (namely, the hunk with the new name). I also don't understand how it passes tests if the title is correct. :) Edit: Or how the patch implements the title at all, actually.
Also, I think that initial patch was just intended as an initial step and more work is outlined in the summary? The "simplify" part. I.e. what Wim said:
Finally, the thing in the title sounds like it would need a change record.
Comment #8
wim leersOh yes this was definitely not yet ready! I said :)
Comment #9
wim leersThis:
onFormatUnknown()onHtml()toonException()onException()It also updates
CommentResourceTestBaseto now assert the more helpful error response that you now get in REST when a fatal error occurs: you get a stack trace there now too, if you have verbose error logging enabled!The end result is that this as the current docblock says has far less complexity: rather than a very complex and brittle format-based redirection, it now always does the same. It's a last-chance thing, after all.
Comment #10
wim leersWith #9,
\Drupal\Tests\Core\EventSubscriber\DefaultExceptionSubscriberTestfails. Because it relies on:error_displayable()(defined inerrors.inc)DRUPAL_ROOT(defined inbootstrap.inc)ERROR_REPORTING_DISPLAY_VERBOSE(defined inbootstrap.inc)So, I had to make a few changes to wrap those in methods I can override for testing purposes.
Comment #11
wim leersThis:
DefaultExceptionSubscribertoFinalExceptionSubscriberexception.defaulttoexception.finalComment #12
wim leersOops, I made two mistakes in #10. It's a good thing we have functional tests :)
Comment #13
wim leersTitle + issue summary updated. CR created: https://www.drupal.org/node/2856738.
Comment #14
dawehnerLooks super good for me!
Comment #19
wim leersComment #20
dawehner<3
Comment #21
wim leers:)
Comment #23
wim leersSigh. After being RTBC for a month, and it being the oldest RTBC issue for a very long time, this random infrastructure fail causes it to be the youngest RTBC issue. Note that https://www.drupal.org/pift-ci-job/634975 does not even list any failing test! :/
Comment #24
alexpottCommitted a0dcc7f and pushed to 8.4.x. Thanks!
Backtraces for REST requests - nice!
Comment #26
wim leers:)
Comment #28
wim leersComment #29
adamps commentedI have found a bug #2924860: “Uncaught exception” page contains HTML but has content-type text/plain which might have been caused by or be related to this issue. I would be grateful if one of the experts here could have a look.