> Le 26 nov. 2018 à 22:42, Nikita Popov <nikita....@gmail.com> a écrit :
> 
> 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

Although this can be viewed as an issue of the silencing operator, this can 
also be viewed as an issue of the default error handler, which should not 
blindly obey the error_reporting() directive (or the @ operator) in case of 
fatal error.

Hopefully, custom error handlers are able to scream even when they are asked to 
shut up.

My suggestion is rather to change the implementation of the default error 
handler, so that it refuses to ever sweep fatal error messages under the rug. 
Code that has legitimate reasons to silence fatal errors can always use a 
custom error handler that will obey it.

(BTW, it could be handy to have the following built-in constant:
const E_ANY_ERROR = E_ERROR | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR | 
E_RECOVERABLE_ERROR | E_PARSE;
and ditto for warnings and notices.)

—Claude



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to