Dan Ackroyd wrote on 08/01/2016 16:26:
On 8 January 2016 at 15:48, Rowan Collins <rowan.coll...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
