[wp-trac] [WordPress Trac] #43712: Improve the user experience when a fatal error or uncaught exception occurs

[WordPress Trac]

#43712: Improve the user experience when a fatal error or uncaught exception occurs
-----------------------------+-----------------------------
 Reporter:  David_Rothstein  |      Owner:
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Bootstrap/Load   |    Version:  trunk
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 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
 [https://api.drupal.org/api/drupal/includes%21theme.inc/function/theme_render_template/7.x
 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
 [https://api.drupal.org/api/drupal/includes%21errors.inc/function/_drupal_log_error/7.x
 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43712>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform