Breaking BC might be unnecessary if instead of changing the default behavior of @, you add an additional flag to error_reporting that enables the new behavior, something like E_UNSILENCE_FATAL. Then developers would only need to switch a flag in php.ini to get the old behavior back, instead of re-working existing code around the new behavior.
On 11/26/18, Nikita Popov <nikita....@gmail.com> 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
