Re: Deprecation of the Error Control Operator (@ symbol)
| From: | Sara Golemon | Date: | Tue, 05 Jan 2016 19:55:48 +0000 |
| Subject: | Re: Deprecation of the Error Control Operator (@ symbol) | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-90143@lists.php.net to get a copy of this message | ||
On Tue, Jan 5, 2016 at 11:40 AM, Rowan Collins <rowan.collins@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)