Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113393
To: internals@lists.php.net
References: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
Message-ID: <ee48e531-4b69-5f0e-7ac8-3e5d67bbba66@gmail.com>
Date: Thu, 4 Mar 2021 22:05:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress
 exceptions
From: rowan.collins@gmail.com (Rowan Tommins)

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]