Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90365
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
References: <CADZXHp6UA4iH6196vN_U+rLSu1Tw+EazQod2LVgwJ7kkUCTd7Q@mail.gmail.com>
 <CA+kxMuQkV=OP2Wt9V6DnebMoBgy6aUf3NmZTDPo_yXXAG5N=Yw@mail.gmail.com>
 <568FDA4B.60005@gmail.com>
 <CA+kxMuRc=ZZuZqY3hrR=14hBrLfSNJ8E8hUbOvp6xe-eyzGU5Q@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <568FE92D.4090001@gmail.com>
Date: Fri, 8 Jan 2016 16:51:57 +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+kxMuRc=ZZuZqY3hrR=14hBrLfSNJ8E8hUbOvp6xe-eyzGU5Q@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 08/01/2016 16:26:
> On 8 January 2016 at 15:48, Rowan Collins <rowan.collins@gmail.com> wrote:
>> It doesn't do anything to help Stas's example for instance:
>>
>> @$counts[$item]++;
> I think that that code is bogus since the release of PHP 7, which made
> it trivial to not use the error suppression for this case, while still
> writing code that doesn't take up multiple lines.
>
> $counts[$item] ?? $counts[$item] = 1 ?? $counts[$item]++;

It's a matter of code style; to me, that's still just noise. If I know 
that $counts is being used as a "hash" (arbitrary keys, defined on 
demand) and not a "struct" (pre-defined keys, accessed dynamically) then 
the first version does exactly what I want it to, and I see no advantage 
in making it more complex.



>> This is not something which should ever throw an exception,
> Oh yes, it definitely should:
>
> $item = new StdClass;
> @$counts[$item] = "This is a bad use of error suppression.";
>
> There is no insertion, because arrays don't support object keys. The
> operation completly failed and so there should be an exception.
> Currently that code fails silently.

OK, fine, let me reword that: the warning "undefined index 'foo'" should 
never be thrown as an exception.

I am absolutely not saying that there aren't cases where we should be 
throwing Exceptions (or Errors, now they exist) rather than Warnings, 
just that there are also cases where warnings are non-fatal, and have 
nothing in common with Exceptions.

The point of the example is not that the @ operator is perfect here, 
it's that sometimes, the ability to suppress specific warnings as "I 
know and don't care" is useful. I just wanted to get people away from 
the example of fopen() which frankly should never be raising a warning 
in the first place.


> I very much look forward to seeing your proposal for this file
> handling API, which is both easy to use, and never throws exceptions
> which people will want to discard.

I detect sarcasm here, and would like to hear a non-sarcastic version of 
your point. Can you give an example of an operation where it would be 
reasonable to throw an exception, but also reasonable (and common enough 
to affect the design of the API) to completely ignore that exception and 
carry on?

If an operation has fatally failed (such as trying to open a 
non-existent file for reading), people will want to have code handling 
that failure, so suppressing the exception would be counter-productive; 
if an operation has encountered an unexpected but non-fatal condition, 
it should signal that with something other than an exception (for 
instance, returning a success boolean or status flag).

Regards,
-- 
Rowan Collins
[IMSoP]