Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
In-Reply-To: <CAESVnVqQKqtn6tEK9CaykCtRkrXq_YXuM429f1cZvPK_5gsLeg@mail.gmail.com>
Date: Tue, 5 Jan 2016 14:24:36 -0600
Cc: Ferenc Kovacs <tyra3l@gmail.com>,
 Andrea Faulds <ajf@ajf.me>,
 Junade Ali <mjsa@junade.com>,
 grzegorz129@gmail.com,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <68A8B669-7A42-41B1-9E1E-9D3441C2AD70@icicle.io>
References: <CADZXHp6UA4iH6196vN_U+rLSu1Tw+EazQod2LVgwJ7kkUCTd7Q@mail.gmail.com> <CAESVnVq0RK-q0UQaqOpEg2=rEwW5znp7d_EoeHLoOsigvM77Sg@mail.gmail.com> <4F.0A.12097.24FFB865@pb1.pair.com> <CAESVnVr2uMOjnTUhcL7b03-Nh4H+z1c5NttF=ykP5DFMmdHHgg@mail.gmail.com> <CAH-PCH5gcWZSae7D1YcB501himD1QOjy7FUGm_4ebjTT-DPofQ@mail.gmail.com> <CAESVnVqQKqtn6tEK9CaykCtRkrXq_YXuM429f1cZvPK_5gsLeg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)
From: aaron@icicle.io (Aaron Piotrowski)


> On Jan 5, 2016, at 12:22 PM, Sara Golemon <pollita@php.net> wrote:
>=20
> On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs <tyra3l@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?
>>>>=20
>>> Nope.
>>> Supressed errors already reach custom error handlers:
>>> https://3v4l.org/TG8aA
>>=20
>> 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;
>>    }
>>=20
>> @ 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.
>>=20
> 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.
>=20

Exactly. There=E2=80=99s 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=