On 11/27/2018 8:26 AM, Nikita Popov wrote:
On Tue, Nov 27, 2018 at 2:20 PM Thomas Hruska <thru...@cubiclesoft.com>
wrote:
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.
I think you are mixing two orthogonal degrees of error configurability
here, which are
a) The error_reporting level, which determines which errors are reported in
the first place, and which is what @ influences, and
b) The display_error, error_log etc. directives, which control what happens
when an error is reported.
The proposed change does not impact b) in any way. If you have
display_errors=Off and use error_log (as you should in production), you use
@ and a fatal error occurs, then (with the proposed change) no error will
be displayed, but it *will* be logged. If you have display_errors=On and
don't use error_log (as is common in development), you use @ and a fatal
error occurs, then (with the proposed change) the error will be directly
displayed. Without the proposed change, in both cases, you would not get an
error, either logged or displayed.
Nikita
The way it was worded sounded like the changes *might* override the
directives in b).
Thanks for the clarification. Carry on.
--
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
