Heejin Ahn

And while these discussion and brainstorming can continue for a long time, I'd like to paste what I wrote to you in one of the replies to your email: >...

@RossTate True, but we decided to remove `unwind` in #156. I think `unwind` + your variant of branching/returning instruction in effect achieves the same thing with `finally`.

@RossTate I'm not sure if I understand what you are suggesting, and I also am not sure if we want to repeat the discussion between `unwind` vs. `catch_all` again. Also...

Also what we should think about are: - What happens when `catch` throws or rethrows? In Java `finally` should run anyway. Then how should we define the semantics of `catch`'s...

@tlively > I would propose adding `try-finally` as a new form in addition to the existing `try-delegate` and `try-catch*-catch_all?` rather than allowing constructs like `try-catch*-catch_all?-finally?`. I believe this would sidestep...

> > The problem is the finally should rethrow, or more precisely pass, the already thrown exception in case the finally is entered by an exception thrown, but the finally...

FYI: It looks when there is a preceding control flow action (branch / return / exception) from `try` or `catch`, and `finally` clause also has its own control flow action,...

@RossTate > That is, if a `finally` clause is being executed due to lexical control flow (in this case, the break), the raise does not resume unwinding or the lexical...

I'll try to sum up the requirements or suggestions so far. I might be missing something or there can be cases I haven't considered; please let me know if so....

@rossberg @tlively > > > * When there is a control flow transfer inside `finally`, the preceding control transfer, if any, is discarded, and the `finally`'s control flow transfer is...