Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89946
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.53 as permitted sender)
To: Junade Ali <mjsa@junade.com>, internals@lists.php.net
References: <CADZXHp6UA4iH6196vN_U+rLSu1Tw+EazQod2LVgwJ7kkUCTd7Q@mail.gmail.com>
Message-ID: <568599AA.4090209@gmail.com>
Date: Thu, 31 Dec 2015 13:10:02 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CADZXHp6UA4iH6196vN_U+rLSu1Tw+EazQod2LVgwJ7kkUCTd7Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I am looking to submit an RFC in order to remove the error suppression
> operator in PHP, namely the @ symbol.

I don't think it is a good idea, currently, for the following reasons:

1. A lot of functions produce error messages which may not be important
in specific scenario, and the users should retain control over if they
want them or not. Checking does not solve the problem, because a) it's a
lot of unnecessary boilerplate code and b) the fact that you checked
doesn't mean the situation is the same when you use what you checked -
and race conditions are hard to debug.
For some functions, you may not be even able to predict when they may
output error messages - such as ones relaying them from third-party
library. Of course, better way to handle them would be to return error
status and use error reporting function, or have structured exception
handling (or both) but it's not the case for many existing functions.

2. There are scenarios where @ saves a bunch of boilerplate code -
simplest example:

@$counts[$item]++;
vs.
if(!isset($counts[$item])) {
  $counts[$item] = 1;
} else {
  $counts[$item]++;
}

Now imagine you have to write 20 of those - which is easier to write
*and* read? Of course, one could argue the notice maybe should not be
produced - but it is.

> Aside from doing this, there are a number of alternatives: re-engineering
> the behaviour of the error suppression operator and potentially bringing
> into the scope of a function (e.g. silence()); this said, I still feel this
> would contain similar issues as it wouldn't address the underlying issues
> of lazy error suppression.

I don't see how that would achieve anything but making it more verbose.
The inherent problem is that some error reporting is unneeded in some
contexts, while welcome in others. That's the problem that needs
solving, the syntax is secondary to it.

> Lastly, I recognise this will be a big change to PHP; but I feel it is
> necessary to enhance the quality of PHP error handling. Let's not forget
> that PHP managed to successfully deprecate the MySQL library.

PHP did not just remove mysql library, it replaced it with better
alternative. Which was well in place when the talk of the removal
started. I agree that PHP error system could use a lot of improvement -
in fact, it already started with move to exceptions and other changes -
but it has to go much further before we could afford to remove @. I
would say it definitely should not happen anywhere in 7.x line.

-- 
Stas Malyshev
smalyshev@gmail.com