> On Jan 5, 2016, at 12:22 PM, Sara Golemon <poll...@php.net> wrote: > > On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: >>>> I don't think that would work out too well. Remember that many projects >>>> have >>>> error handles which convert all errors to exceptions: if you disable @ >>>> in >>>> those projects, wouldn't their code break? >>>> >>> Nope. >>> Supressed errors already reach custom error handlers: >>> https://3v4l.org/TG8aA >> >> sure and most projects check the error_reporting() level against the $errno >> like in the manual: >> if (!(error_reporting() & $errno)) { >> // This error code is not included in error_reporting >> return; >> } >> >> @ changes the error_reporting() level for that particular call, so those >> custom error handler won't throw exceptions for the suppressed errors but >> when you remove/nop @ their code would throwing stuff left and right. >> > Today I learned... Okay, def a problem (for a specific set of > circumstances). And one which makes me more amenable to Ze'ev > declare() suggestion (on a per-request bases, not per-file) as anyone > modifying a project's codebase for testing can also modify it to > suppress those exceptions as needed and/or just not enable the custom > error handler. >
Exactly. There’s no need for a new ini setting, since an error handler can be written that ignores the current error level and throws an exception or does whatever the coder wants. Abuse is the only real problem with the @ operator. Coders use it in place of proper state or error checking. However, there are legitimate uses such as with fwrite, fopen, stream_select, etc. that Grzegorz Zdanowski and I pointed out. Before anything can be done with the @ operator, changes will need to be made to remove warnings for conditions that the code has no way of checking prior to calling these functions. Setting a custom error handler before calling these functions and removing the error handler afterwards is a clunky solution. Any proposal to remove the @ operator needs to address how functions issuing unavoidable warnings will be changed. Aaron Piotrowski https://trowski.com @trowski2002 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
