On Mon, Dec 3, 2018 at 12:51 AM Andrea Faulds <a...@ajf.me> wrote: > Hi Nikita, > > Nikita Popov wrote: > > 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. > It's always been bizarre to me that @ can silence fatal errors, which > has no practical application and makes using @ to silence a lower-level > error potentially hszardous if its targeted function can also produce a > fatal error. >
Well, it does have one practical application which I think we should pay attention to if we are to change the behavior - in case of display_errors being on (yes, nobody should have that in production, but that doesn't change the fact that many do) - suddenly we would potentially be exposing sensitive data to remote users - data that was previously explicitly silenced and with this change we'd be breaking that contract. This is not an unlikely scenario. OTOH I do see the value of being able to silence only non-critical messages. What if we do something along the lines of what somebody proposed, and introduce another error level E_ERROR_WHILE_SILENCED or something like that? Folks who would want to will be able to turn it on, and we can leave it out of E_ALL so that it would require explicit enabling. Zeev
