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
