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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
