On Tue, Jan 5, 2016 at 11:40 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
>> @ 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.
>
>
> I'm lost - how does this validate the claim that building scream mode into
> core would lead to problems? We already have an ini setting which can change
> the error_reporting level, so any error handler relying on that is *already*
> subject to different behaviour in different environments. Any codebase which
> wants to ignore the settings of the environment would surely already omit
> that boilerplate, and thus be unaffected by the presence or functionality of
> the @ operator.
>
Because no matter how high your error_reporting is set (globally,
per-dir, or ini-set) the @ suppression operator temporarily resets it
to zero. In psuedo-code the following two blocks are equivalent:
@foo();
if (ini_get('scream')) {
$old_reporting = error_reporting(0);
}
foo();
if (ini_get('scream')) {
error_reporting($old_reporting);
}
So the argument being made is that being able to disable @ suppression
means ignoring whatever value the developer/admin has set for
error_reporting.
-Sara (not taking a stand on whether that's a compelling argument,
just clarifying it)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
