Improve the user experience when a fatal error or uncaught exception occurs

[David_Rothstein]

If a WordPress page request dies with a catchable fatal error or uncaught exception, WordPress just falls back on PHP's default error handling behavior. What this typically means is:

• The page HTML gets cut off at a random point (wherever the error occurred), so the page looks broken but with no indication to the user that anything went wrong.
• The request returns with a 200 status (which can result in the broken page being cached in all sorts of places).

Proposed improvement:

• Use set_error_handler() and set_exception_handler() early in the WordPress bootstrap process to give a better experience by default.

For comparison, the way Drupal handles this is that it ​buffers all output from the theme (only actually printing it much later on in the page request). That way, if a fatal error or exception does occur, no output has been sent yet, so it can always ​set a "500 Service unavailable" header and display a maintenance page instead.

There are pros and cons to that approach, but in any case, I'm not sure that WordPress could be changed to use it in a backwards-compatible way.

However, what does seem possible to me is:

• The error handler could check headers_sent() to see if output was already sent.
• If no output was sent yet, just call wp_die() to display a standard error page with a 500 error.
• If output already was sent, maybe at least try to print some kind of HTML before dying so the user can see that something is broken which wasn't their fault. I'm thinking something like an "Oops - something went wrong and the page didn't finish loading" message, ideally themed as a simple floating bar at the bottom of the browser window.

[jorbin]

Hi @David_Rothstein, sorry it's taken so long to respond and thank you for opening this ticket.

In WordPress 5.2, ​fatal error recovery mode was introduced. I am going to close this as a duplicate of #44458 which is where that feature was originally introduced.