Re: Don't silence fatal errors

On 11/26/2018 2:42 PM, Nikita Popov wrote:

Hi internals, When the silencing operator @ is used, the intention is generally to silence expected warnings or notices. However, it currently also silences fatal errors. As fatal errors also abort request execution, the result will often be a hard to debug white screen of death. The most recent occurrence which motivated me to write this mail is https://bugs.php.net/bug.php?id=77205, but I've seen this play out multiple times already. I would like to propose to change the behavior of @ to only silence warnings, notices and other low-level diagnostics, but leave fatal errors intake. In particular, the following should not be silenced: * E_ERROR * E_CORE_ERROR * E_COMPILE_ERROR * E_USER_ERROR * E_RECOVERABLE_ERROR * E_PARSE This change would have two main implications for backwards compatibility: 1. Code that legitimately wants to silence fatal errors for whatever reason should now use error_reporting() (or ini_set()) to do so, instead of @. 2. Error handlers that want to only handle non-silenced errors may have to be adjusted. A common pattern I found in our own tests if checks for error_reporting() != 0 to detect silencing. This should be changed to error_reporting() & $err_no to detect whether the specific error type is silenced. A preliminary patch for this change is available at https://github.com/php/php-src/pull/3685. What do you think about this? Nikita

Instead of a blank screen (or early termination if some output has been sent), maybe emit, "[GMT date/time] A fatal error occurred. Check the error logs." The only bug I see here is that fatal errors are being suppressed from reaching the log files. But they should still be suppressed from the browser/client if the INI settings are configured to send messages to the logs. WSODs should have been fixed a long time ago to emit a simple, generic message to check the logs (i.e. no more WSODs). The average WSOD is usually accompanied with a HTTP 500 response but having to look at network tools tab to see the 500 is an extra step. A surprising number of developers I encounter don't know what a HTTP 500 means nor what to do when they encounter one. Therefore, helpful but very generic directions would be useful and save a few moments of head-scratching. Also, forcing users to override the default error handler to restore previous (and almost correct) behavior is a bit obnoxious. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/