Re: Don't silence fatal errors

On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov <nikita.ppv@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 > I'd like to move forward with this change. I think the overall reception here has been positive, although in the discussion some other possibilities that avoid/reduce the BC aspect have been discussed. I think now that we have a PHP 8 branch, it would make sense to apply this as-is. The BC break is quite minor (compared to the other changes in PHP 8) and I think this is the cleanest way to solve the problem, as it only changes the list of silences errors, without introducing any new error handling concepts or mechanisms. Nikita