Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90089
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
To: internals@lists.php.net
References: <CADZXHp6UA4iH6196vN_U+rLSu1Tw+EazQod2LVgwJ7kkUCTd7Q@mail.gmail.com>
 <CAESVnVq0RK-q0UQaqOpEg2=rEwW5znp7d_EoeHLoOsigvM77Sg@mail.gmail.com>
 <CAOhe--M_EpntLzgH7eMF++011mUahH+xFO_np=b_bfu8bFVQxw@mail.gmail.com>
 <alpine.DEB.2.20.1601051054320.4541@whisky.home.derickrethans.nl>
 <cf9a1658f7e947399c56e8606be90359@mail.gmail.com>
 <CAAoDVDB=aOEZ3ymJn6nC=bDyVEks3YGqp_5T2HdS6YCoYSaeMQ@mail.gmail.com>
Message-ID: <568BC9CF.1080000@gmail.com>
Date: Tue, 5 Jan 2016 13:49:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CAAoDVDB=aOEZ3ymJn6nC=bDyVEks3YGqp_5T2HdS6YCoYSaeMQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)
From: rowan.collins@gmail.com (Rowan Collins)

Grzegorz Zdanowski wrote on 05/01/2016 12:27:
> Before deprecating @ operator I think we should make a RFC which cover
> unified setting to convert all E_* to exceptions (like
> PhpWarningException). I know it's just a temporary solution, because
> exception should be more specific, but it's a huge amount of work to
> replace all errors and warnings with proper exceptions.

This is definitely not the solution. I've seen this suggested a few 
times over the years, and every time people seem to miss a vital point: 
Warnings are not, in general, a fatal situation. A useful rule of thumb 
I heard for "should I throw an exception?" is "would I be happy to use a 
die() statement?"

Even if you don't accept that, the main purpose of an exception is to 
force the code down a different path. (I've seen lots of discussions 
about exceptions being great because they have stack traces, but have 
never understood why any other mechanism couldn't also have those).

In a few places, like the file-handle API, the Warning is accompanied by 
an invalid return value (usually false) and probably should be an 
exception - the code will definitely need to follow a different path, 
and dying would often be better than proceeding with an invalid handle 
(which will probably end up fatal later).

But in many cases, an E_WARNING (or an E_NOTICE) really is just a 
warning - most code *doesn't* want to go down an alternative path, but 
it might want to log a message. In a few cases, code does want to go 
down a different path, and currently has to use the "error handler" 
infrastructure. In other cases, code wants to never log the message, and 
currently has to use the @ operator.

The main problem, in my opinion, with the current system of "errors" 
(better called "messages") is that they provide only two pieces of 
identifying information: an integer representing severity, from a small 
list; and a string which may have placeholders, may change between 
versions, and does not come from a documented list. This means you can 
say "suppress everything with E_NOTICE severity" but not "suppress all 
array-assignment warnings"; and you can set up an error handler to 
convert everything into exceptions, but a handler to convert all 
file-handle warnings into exceptions would have to pattern-match every 
message string to identify them.

The only way out of this that I can see is to replace the current 
string-based internal message APIs with something that forces the 
extension developer to pre-define a set of codes, and provide the 
substitution parameters for the error directly. This could then allow 
more information to be exposed to userland, and more granular stacking 
of handlers and configuration to mask off different types based on their 
codes.

Regards,
-- 
Rowan Collins
[IMSoP]