[kfuse]

That's not just Java and there is nothing really cursed about it: throwing in a finally block is the most common example. Jump statements are no different, you can't just ignore them when they override the return or throw statements.

[Maxatar]

It is just Java as far as I can tell. Other languages with a finally don't allow for explicitly exiting the finally block.

[maxdamantus]

And JavaScript .. And Python (though as sibling posts have mentioned it looks like they're intending to make a breaking change to remove it).

EDIT: actually, the PEP points out that they intend for it to only be a warning in CPython, to avoid the breaking change

[ajb]

Modula-3 has it despite not having a continue statement:

https://www.cs.purdue.edu/homes/hosking/m3/reference/exit.ht...

But there, it's more comprensible because in order to define the interaction of return (and exit) with exceptions, they define return, and exit, to be exceptions. So then it's more obvious why return can be "caught".

[o11c]

Notably, C++ and similar languages don't support lexical `finally` at all, instead relying on destructors, which are a function and obviously cannot affect the control flow of their caller ...

except by throwing exceptions, which is a different problem that there's no "good" solution to (during unwinding, that is).

[kmeisthax]

I thought destructors were all noexcept now... or at the very least if you didn't noexcept, and then threw something, it just killed the process.

Although, strictly speaking, they could have each exception also hold a reference to the prior exception that caused the excepting object to be destroyed. This forms an intrusive linked list of exceptions. Problem is, in C++ you can throw any value, so there isn't exactly any standard way for you to get the precursor exception, or any standard way for the language to tell the exception what its precursor was. In Python they could just add a field to the BaseException class that all throwables have to inherit from.

[aw1621107]

> I thought destructors were all noexcept now...

Destructors are noexcept by default, but that can be overridden with noexcept(false).

> or at the very least if you didn't noexcept, and then threw something, it just killed the process.

IIRC throwing out of a destructor that's marked noexcept(false) terminates the process only if you're already unwinding from something else. Otherwise the exception should be thrown "normally".

[MangoToupe]

> override the return

How is this not cursed

[metaltyphoon]

It is Java as C# disallow this