On Thu, 4 Mar 2021 at 22:05, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> 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". > Took me a while to read this article, which was very interesting. > 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". > This is an interesting idea, and relatively easy to change with my current PoC. However, in that case investigating how to prevent the creation of the exception altogether is something that will need to be investigated as the creation of an exception remains expensive On Sat, 6 Mar 2021 at 13:57, Rowan Tommins <rowan.coll...@gmail.com> wrote: > That means a lot of people would still need to change their code if > fopen() started throwing exceptions, weakening advantage #2. > > > If you make people opt into exceptions, e.g. using > declare(throw_on_error=1) then you actually lose *both* advantages: > > 1. Every file you add the new declare() line to will no longer run on > older versions of PHP. > 2. Since you're changing every file anyway, in a non-compatible way, you > can do some find-and-replace at the same time. For instance, changing > "if(@fopen($filename))" into "if(try(fopen($filename)))". > > I'm also not convinced a file-level opt-in is a sensible long-term > strategy. The risk of writing code assuming one error style in a file > actually set to the other seems too high. > Frankly I would prefer this to be part of an edition mechanism as I would not want this to be a permanent addition to the language due to the disadvantages that you've listed which I am aware of. But until such a mechanism is introduced into PHP, a declare statement is the best next thing that I can think of. > The more I think about it, the more I get the feeling that while this > proposal has some great ideas, it hasn't got the combination quite right > yet. > And that's why I'm publishing it on the list, because the issue is rather complicated and I don't think I can figure it out on my own. > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Best regards, George P. Banyard
