In fact, if we want to go all-in with this style, we could remove the if/else construction altogether (from the language!) and do everything using exceptions. Since they are good for control flow, why stop here?
This is much clearer, since the "normal" flow of execution is emphasized, and it avoids using an ad-hoc legacy if/else construct. Moreover, it has the advantage that statement_2 can be hidden into another part of your program, wherever you want to catch this exception.
I was thinking more of making a parallel with effect handler system currently in development for Ocaml and other research languages, you do something similar to throwing a continuations[0][1][2].
It is proposed as an alternative to both the current monad-oriented approach used in Haskell and the procedural side-effects of OCaml.
To my understanding the base idea is that you can register "handlers" for (user defined) "effects" that can be emitted from normal code.
Once an effect is emitted the handler receives a continuation and can decide what to do with it (call it immediately, register it in a async/await pool, repeat it 5 times).
It would offer a type safe way to implement async/await as library code, which sounds quite cool.
The proposed try/catch/continue was a silly bastardization of this idea.
The old-fashioned
now becomes This is much clearer, since the "normal" flow of execution is emphasized, and it avoids using an ad-hoc legacy if/else construct. Moreover, it has the advantage that statement_2 can be hidden into another part of your program, wherever you want to catch this exception.