Comment by marginalia_nu

I would not call this snippet particularly "cursed". There is no "aktshchually this happens, therefore this is activated" hidden magic going on. The try-catch-finally construct is doing exactly what it is designed and documented to do: finally block is executed regardless of the outcome within try. The purpose of finally block is to fire regardless of exceptionality in control flow.

Surprising at first? Maybe. Cursed? Wouldn't say so. It is merely unconventional use of the construct.

That was a great talk. I was somewhat skeptical of this change, but she really looked at it from every angle and makes a strong argument for the benefits of disallowing the construct. Also, I didn't know that (as mentioned in the talk) C# already disallows it.

> Having the retry logic within the `finally` block seems like the best way of denoting the intention to me, since the intention is to swallow the result, whether that was a return or a throw.

Except that is not the documented intent of the `finally` construct:

  The finally block always executes when the try block exits. 
  This ensures that the finally block is executed even if an 
  unexpected exception occurs. But finally is useful for more 
  than just exception handling — it allows the programmer to 
  avoid having cleanup code accidentally bypassed by a 
  return, continue, or break. Putting cleanup code in a 
  finally block is always a good practice, even when no 
  exceptions are anticipated.[0]

Using `finally` for implementing retry logic can be done, as you have illustrated, but that does not mean it is "the best way of denoting the intention." One could argue this is a construct specific to Java (the language) and does not make sense outside of this particular language-specific idiom.

Conceptually, "retries" are not "cleanup code."

0 - https://docs.oracle.com/javase/tutorial/essential/exceptions...

Doesn't that code ignore errors even if it runs out of retries? Don't you want to log every Exception that happens, even if the transaction will be retried?

This code is totally rotten.

> if (!tx.commit())

https://docs.oracle.com/javase/8/docs/api/java/sql/Connectio...:

  void commit()
     throws SQLException

⇒ this code I won’t even compile for the java.sql.Transaction” class that is part of the Java platform.

(I think having commit throw on error is fairly common. Examples: C# (https://learn.microsoft.com/en-us/dotnet/api/system.data.sql...), Python (https://docs.python.org/3/library/sqlite3.html#sqlite3.Conne...))

This code is wrong. You don't want to commit a transaction if an exception is thrown during the transaction.

This loops, if that's what you're asking:

    while (true)
    {
        try
        {
            try { return; }
            finally { throw new Exception(); }
        }
        catch { }
    }

Yes that is the one exception (heh) to the rule unfortunately. You can throw from anywhere so it must support unwinding from any point. So if you were really intent on abusing the finally you could wrap the try-finally in a try-catch and then throw from the finally and put your continue in the catch.

ziml77's point is about the behaviour of the C# language. You seem to be talking about implementation concerns. They're not relevant.

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

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).