On 04/03/2021 14:08, G. P. B. wrote:
This new RFC which I'm proposing is to extend the capability of the error
control operator @ to not just suppress diagnostic messages but also
exceptions.
It can currently be found on GitHub: [1]
https://github.com/Girgias/error-control-operator-exceptions-rfc
Hi George,
This is a really creative approach to this thorny problem, and I think I
like it, although I'm still working through the implications in my head.
One thing I'd like to call out is that this could be useful in its own
right, outside of migration strategies.
One of the big downsides of exceptions is that they always cause control
to jump somewhere else, even when you'd rather they didn't. Joe Duffy in
an interesting blog post [1] about error handling strategies refers to
it as "control-flow rather than dataflow".
For instance, if you start with this:
$foo = doSomething() + $bar;
If doSomething() throws an exception, and you want to default to just
$bar, you have to write this:
try {
$foo = doSomething() + $bar;
}
catch ( SomeException $e ) {
$foo = $bar;
}
What you really want is to catch the exception, but not break the flow.
With this proposal you could:
$foo = ( @<SomeException>doSomething() ?? 0 ) + $offset;
Which leads me to suggest changing this:
> As such @<\Throwable>expression and @expression are identical.
To this:
> When a class list is given, the operator will not suppress raised
errors (E_WARNING, E_NOTICE, etc). So @<\Throwable>expression will
suppress all possible Exceptions, it does not have the same behaviour as
@expression.
This makes the operator useful even in situations where you want normal
error handling behaviour (e.g. logging) for Warnings and Notices, but
want to force an exception back into "dataflow style".
[1] http://joeduffyblog.com/2016/02/07/the-error-model/
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
