Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90358
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
To: internals@lists.php.net
References: <CADZXHp6UA4iH6196vN_U+rLSu1Tw+EazQod2LVgwJ7kkUCTd7Q@mail.gmail.com>
 <CA+kxMuQkV=OP2Wt9V6DnebMoBgy6aUf3NmZTDPo_yXXAG5N=Yw@mail.gmail.com>
Message-ID: <568FDA4B.60005@gmail.com>
Date: Fri, 8 Jan 2016 15:48:27 +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: <CA+kxMuQkV=OP2Wt9V6DnebMoBgy6aUf3NmZTDPo_yXXAG5N=Yw@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)

Dan Ackroyd wrote on 06/01/2016 17:12:
> Work on a plan on how to migrate all internal errors/warnings to
> individual exceptions. The current way of using set_error_handler to
> convert warnings/errors into generic exceptions isn't good enough.

Again, you're focussing exclusively on that sub-set of warnings which 
are actually errors in disguise.

I think it would be perfectly reasonable to implement a new file 
handling API, which behaves like modern PHP (objects, exceptions, etc) 
rather than being a thin wrapper for C (which is why fopen() does what 
it does). There'd then be no particular need to "suppress" any 
exceptions thrown from that, because if the handle is invalid, you 
actually need to do something different in the catch clause. In the 
current C-based API, the "catch" is the "if ( $fh === false )"; the 
warning is actually superfluous, hence the desire to suppress it.

But this doesn't actually present a solution to the dozens of other 
warnings and notices. It doesn't do anything to help Stas's example for 
instance:

@$counts[$item]++;


This is not something which should ever throw an exception, however easy that exception was to discard.

On the other hand, the "suppress" operator might be usable in conjunction with categorised warnings; e.g.

$counts[$item]++ suppress ET_ARRAY_NOSUCHKEY;


I would also contend that a correctly thrown exception should never be something you want to just suppress - at the very least, you want to log it, and probably you want to skip or add some logic. For instance, this makes no sense to me:

$db = new PDO($dsn) suppress PDO_Exception;
// oops, now I have to check if $db instanceof PDO, rather than just jumping to catch/finally


@ doesn't suppress exceptions, nor does it stop fatal errors being fatal; nor should its replacement.


Regards,
-- 
Rowan Collins
[IMSoP]