develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Pre-RFC: try/catch/finally and generic finally blocks

Thread Previous | Thread Next
Paul "LeoNerd" Evans
January 21, 2022 17:18
Re: Pre-RFC: try/catch/finally and generic finally blocks
Message ID:
On Wed, 19 Jan 2022 13:46:58 -0600
David Nicol <> wrote:

> My expectations of what next/last/redo would do in a finally block
> are as follows:
>    - last jumps to the end of the finally block

`last` doesn't jump out of an if, else, try, catch, or defer block. Why
should `finally` be any different?

>    - redo starts the finally block over (not the exception handler,
> but you should be able to get there with goto label)

Same question as above.

>    - next jumps to the test for the outer interator, if any, as if it
> was stated outside of the construct. Why is next even an issue in
>    try/catch/finally? it isn't an interator.

`next` is only a problem for the same reason that any of the loopex,
goto or return are a problem. They're a problem because they cause a
control flow jump directly out of the block.

This is a problem for two reasons:

 1) Annoying "this is hard to implement" reasons.

 2) Fundamental semantic "this is meaningless" reasons.


  sub f {
    defer { return 123; }
    die "Ooops\n";

What should be the result of calling f()? Once the `die` line is hit,
we're committed to throwing an exception. The defer block gets invoked
as part of scope unwind, but should it be permitted to `return`? Does
it cause the call to f() to return that value and stop the exception
propagating? In effect we've now cancelled the exception.

This isn't the way that defer- or finally-alike constructions work in
basically any other language. It would be a bad model for us to follow.

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About