<p>Regarding gasche's answer - it's true that "you are certainly adding non-trivial complexity to the language", but it's important to keep in mind that in Common Lisp and related languages, conditions are <em>orthogonal to control flow</em>.  The core of condition handling is merely a pattern for looking up handler functions, and does not in any way alter existing or add new control flow powers to the language.  See this sketch of a "condition system" in JS:</p>

<p><a href="https://groups.google.com/forum/?fromgroups#!msg/ll-next/mlixSOPwc-c/iQ-xPd-kIjEJ" rel="nofollow">https://groups.google.com/forum/?fromgroups#!msg/ll-next/mlixSOPwc-c/iQ-xPd-kIjEJ</a></p>

CC BY-SA 3.0
2012-04-12T21:57:43.570Z
I am really glad to see this clarification.  So, the Common Lisp condition system decouples exception throwing (meaning, nonlocal-exits) from condition handling.  It seems wrong to characterize it as "resumable exceptions".
Uday Reddy
CC BY-SA 3.0
2012-04-13T10:32:51.907Z
Right. In CL you have primitives for nonlocal exits (confusingly called [`throw`](http://www.lispworks.com/documentation/lw50/CLHS/Body/s_throw.htm) and [`catch`](http://www.lispworks.com/documentation/lw50/CLHS/Body/s_catch.htm)), and then you have the orthogonal condition system of [`signal`](http://www.lispworks.com/documentation/lw50/CLHS/Body/f_signal.htm) and [`handler-bind`](http://www.lispworks.com/documentation/lw50/CLHS/Body/m_handle.htm).
Manuel Simoni
CC BY-SA 3.0
2012-04-13T10:34:49.470Z
[`handler-case`](http://www.lispworks.com/documentation/lw50/CLHS/Body/m_hand_1.htm) which comes closest to Java's try/catch is actually a combination of the two systems (see the **Notes** section; `block`, `return-from`, and `tagbody` are [variations](http://home.pipeline.com/~hbaker1/MetaCircular.html) on `throw` and `catch`) -- making the point that Java and similar languages conflate condition handling and control.
Manuel Simoni
CC BY-SA 3.0
2012-04-11T08:30:52.500Z
2012-04-11T08:30:52.500Z
Manuel Simoni
<blockquote>
  <p>e.g. in a function that "yields" one result at a time; an unexpected condition could occur while producing one of these results, and you may want the calling code to decide whether or not it makes sense to continue producing more results</p>
</blockquote>

<p>I think you are describing coroutines a la <a href="http://wla.berkeley.edu/~cs61a/fa11/lectures/streams.html#coroutines" rel="nofollow">http://wla.berkeley.edu/~cs61a/fa11/lectures/streams.html#coroutines</a></p>

CC BY-SA 3.0
2015-06-03T04:08:13.433Z
Could you elaborate on your answer and why you think that this is the case?
chazisop
CC BY-SA 3.0
2015-06-03T00:39:41.977Z
2015-06-03T00:39:41.977Z
Jon
<p>"Resumable exceptions" are indeed a well-known idea in some programming language circles. In particular, Common Lisp has had resumable exceptions for a long time (so they are really not confined to research language; Common Lisp could be considered "mainstream", it has been widely available and relatively widely used for a long time).</p>

<p>For a discussion of resumable (or "restartable") exceptions, see for example <a href="http://axisofeval.blogspot.fr/2012/01/restartable-exceptions.html">this blog post</a> by Manuel Simoni, which links to <a href="https://groups.google.com/forum/?fromgroups#!topic/comp.lang.dylan/gszO7d7BAok">this dylan mailing-list post</a> by Chris Double and the following Lambda-the-Ultimate discussion: <a href="http://lambda-the-ultimate.org/node/1544">Common Lisp exception handling</a>.</p>

<p>You made the insightful guess, that resumable exceptions are not a good idea in all contexts. They can make resource handling harder and more generally anything related to side-effects must be considered very carefully when you add new control-flow entry points to a block of code.</p>

<p>It is possible for the exception raising code to decide on whether it should be resumable or not. This is natural if you see resumable exceptions as a combination of usual exceptions and continuations: you raise an exception and, in the attached data, decide whether or not to include a continuation to the rest of the computation; the handler then decide whether or not to invoke that continuation, that is "resume" the exception.</p>

<p>Effect handlers (<code>try..catch</code> block, <code>using</code>-like resource handler assuming lexical lifetime) can get confused if you re-enter the computation. Combining handlers and rich control flow is difficult and gave way to a lot of different approaches in the Lisp/Scheme communities (keywords: <code>dynamic-wind</code>, <code>unwind-protect</code>). You are certainly adding non-trivial complexity to the language.</p>

<p>I speak of "effect handlers" because, once you have such rich forms of control flow, you get very close to the ability of presenting arbitrary effects (exceptions, backtracking, but also logging, mutable state and input/output) on top of it. See for example Andrej Bauer and Matija Pretnar's work on <a href="http://math.andrej.com/2012/03/08/programming-with-algebraic-effects-and-handlers/">Eff</a> a language based on such "effect handlers".</p>

CC BY-SA 3.0
2012-04-07T14:00:44.263Z
Thank you so much for elaborating on this. This board needs more people like you.
mindplay.dk
CC BY-SA 3.0
2012-04-07T22:30:04.797Z
So, the handler than has to fix the state so that the program can resume from where it broke.  That seems like a tall order.  Are there good examples of such handlers?
Uday Reddy
CC BY-SA 3.0
2012-04-07T23:55:11.727Z
@Uday no, I don't think that's expected, perhaps not even possible? that's why I proposed that interrupts be a subtype of exceptions, and that only interrupts can be resumed. The handler has to decide whether it's safe to resume or not, and the throwing code should throw an interrupt (as opposed to an exception) only if it's own internal state is still valid and it is able to continue. If you could resume after just any exception, the results would be entirely unpredictable.
mindplay.dk
CC BY-SA 3.0
2012-04-08T07:39:13.130Z
@Uday the common example is interactive program development; you have a running system that suddenly gets in an error state for some reason (probably a bug), and the exception handler is the debugger, a kind of REPL that has information about where in the program the error occurred *and* the possibility to resume the program at this point, or at the start of any enclosing function call. So you look at the code, look at the variable states, makes a few change, decide from where it's safe to continue, and voilà, your app continues running without having to be restarted.
gasche
CC BY-SA 3.0
2012-04-11T16:59:05.073Z
A better link to Eff is http://math.andrej.com/eff/. I think we need some video tutorials about Eff, don't you?
Andrej Bauer
CC BY-SA 3.0
2012-04-11T20:04:43.290Z
Sorry to be nitpicking, @Andrej, but the page I linked to refers to the one you proposed, while the reverse is only indirectly true, and the one I gave has the interesting discussion with Arnaud that the other lacks. Finally, I personally have a strong dislike for video tutorials; videos are much too inefficient to consume for the reader and my plate is already full so I never watch a video online. Having videos as a complement may help you reach different audiences, but I don't remember meeting someone that preferred them.
gasche
CC BY-SA 3.0
2012-04-11T20:10:05.797Z
@Andrej What I would personally like is a document that would present the relation between the practical aspects of Eff and the underlying theory, for someone that is familiar with type systems but not the algebraic effect literature. And more blog posts about the type system design, which has currently been swept under the rug from "we have no types" to "we have ML types". I think the hesitation, choices and rationale are interesting to hobby language designers, and the effect systems you must be contemplating certainly have their lot of hesitations.
gasche
CC BY-SA 3.0
2012-04-11T20:16:22.747Z
Well, I am not sure why you think we swept the type system under the rug. We first had none, so we couldn't sweep it under the rug, and now we have one, and it is described in the paper. Perhaps you would like us to also explain how type inference works (rather than type checking)? This is completely standard and would get thrown out by a referee. But I agree, perhaps a technical report with more details would help. Or you could read the source code :-)
Andrej Bauer
CC BY-SA 3.0
2012-04-11T20:18:49.410Z
It is true we have not explained how types are to be interpreted in the denotational semantics, though. This is also "standard" to about 200 people. It would deserve an explanation.
Andrej Bauer
CC BY-SA 3.0
2012-04-12T03:43:00.247Z
Sorry for being unclear, I did not mean that your current explanation of types is not problematic; only that once you had no types and didn't see how to get them, and now you have a type system that you describe as a finished, done deal, and I have not seen explanations of what seemed problematic, how you solved it -- or not -- by making which choices, and if you plan to evolve it, why, and in which direction. The paper gave me the impression that the type system was mentioned, but not really discussed; indeed the focus was on the dynamic semantics and concrete examples -- which is fine.
gasche
CC BY-SA 3.0
2012-04-12T12:41:43.003Z
We did not have a type system because we did not think about it at first. But we always knew it was going to exist. Now it exists. It is going in the direction of an efect system as we speak.
Andrej Bauer
CC BY-SA 3.0
2016-10-10T13:38:35.530Z
The problem with resource management and continuations is tied to "dynamic-unwind", which might be problematic. The difference in Common Lisp is that "handler-bind" establishes handlers that run in the context of the exception being thrown, thus not unwinding the stack. I think you already know it, but maybe this should be made explicit in the answer.
coredump
CC BY-SA 3.0
2012-04-07T09:21:47.103Z
2012-04-07T09:21:47.103Z
gasche
<p>I know that Exceptions as a means of flow-control is generally frowned upon.</p>

<p>But in my opinion, Exceptions have little value short of the flow-control aspect - after all, if you didn't want the program to continue, you could just output an error-message an terminate the program.</p>

<p>Exceptions, on the other hand, provide a means of reporting errors "locally", allowing a service/component to fail, and a consumer to handle the failure - and regardless of how you look at that, it is a means of controlling the flow of the program.</p>

<p>So here's my question - over the years, I have frequently wondered, why isn't it possible to <em>resume</em> execution after an exception is thrown?</p>

<p>Now, you wouldn't want to allow any consumer to resume after an Exception thrown by any other component, as that component was probably not designed to resume after a throw-statement, which would lead to unpredictable results.</p>

<p>So let's say there's a supertype of Exception called Interrupt, that allows this behavior. An Interrupt would behave just like an Exception in every respect, except that by throwing an Interrupt, you indicate that the component is ready and able to resume execution after the throw-statement, and that the stack needs to be preserved either until (A) the Interrupt has been handled, or (B) the program exits with an error-message.</p>

<p>Let's say we add a new "resume" statement to the language, to be used inside a traditional "catch" block - if you catch an Interrupt, and issue a "resume" statement, control would return to the point from where the Interrupt was originally thrown, and execution would continue from the next statement.</p>

<p>I've presented this idea in other circles, and I'm met with a lot of resistance, but no clear argument as to why this is not a good idea.</p>

<p>To me, it seems like a natural extension of the idea of exceptions - there are plenty of cases where this could be useful, for example while enumerating a sequence, e.g. in a function that "yields" one result at a time; an unexpected condition could occur while producing one of these results, and you may want the <em>calling</em> code to decide whether or not it makes sense to continue producing more results.</p>

<p>An exception does not allow for that.</p>

<p>Let's say this function throws an interrupt instead - if so, the calling code now has a chance to look at that and decide whether to resume execution (as if the exception never occurred) and produce more results, perhaps log the condition and then resume, or perhaps throw an exception, or perhaps re-throw the interrupt in case it can be handled up-stream.</p>

<p>I'm sure I'm not the first person to have this idea, but I would like to understand why this isn't feasible or why it's not a good idea.</p>

<p>(PS: I'm a programmer, not a scientist, so go easy on me.)</p>

CC BY-SA 3.0
2012-04-06T14:40:58.680Z
I'm inclined to disagree with the premise of your question. Exceptions
are a means of control-flow manipulation, that's the whole point of
exceptions. More precisely, they are a form of non-local 'jump' where
the target of the jump (the place the program jumps to) is dynamically
bound. In some contexts (e.g. Java or C++) it's considered bad style
to use this non-local jumping for anything other than handling of
error conditions that are not locally resolvable. But that's mostly
because in these contexts exceptions are slow, not because of some
fundamental restriction of exceptions.
Martin Berger
CC BY-SA 3.0
2012-04-06T14:41:44.903Z
Resumable exceptions have been investigated (e.g. they were discussed
for C++), but they are hard to implement, they unconstrained use leads to
badly structured programs,  and generally not considered
worthwhile.
Martin Berger
CC BY-SA 3.0
2012-04-06T15:26:47.690Z
@MartinBerger  It seems to me that this should be migrated to cs.SE - thoughts ?
Suresh Venkat
CC BY-SA 3.0
2012-04-06T16:08:48.303Z
@Suresh. I have no objections, given the original question, although there are some interesting theoretical questions about resumable exceptions.
Martin Berger
CC BY-SA 3.0
2012-04-06T21:09:33.293Z
Well, I don't understand the question.  If the component is able to resume after the point where the error arose, why does it bother to raise an exception at all?  Generally, you throw an exception when it is not possible to resume, or it is meaningless to resume, or it is unsafe to resume.
Uday Reddy
CC BY-SA 3.0
2012-04-06T23:32:12.717Z
@SureshVenkat The question is a bit rambling and could use some tightening up (mindplay.dk: this reads more like a position statement, i.e. a rant, than a question), but there is a real question in here, asking for an explanation of resumable exceptions and call/cc. I say migrate away.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2012-04-07T08:52:37.857Z
I'm getting a bit tired of the systematic way questions get closed here. I subscribe to the syndication stream of some tags on cstheory.stackexchange, but when I come to see a question, expecting maybe a discussion about the question, 9 times out of 10 there is instead a discussion about why this question is inappropriate and should be moved elsewhere.
gasche
CC BY-SA 3.0
2012-04-07T08:57:43.747Z
I think there is something obsessive about categorizing questions in just the exact subsubforum (oh no this is not Theoretical Computer Science but Computer Science, oh maybe it's rather Software Engineering...). The boundaries of those domains are fuzzy and I think we should accept that. It would be better if people answered questions that they find interesting, moderated obvious, non-controversial mischaracterizations, but refrained from collectively closing questions that they find a bit over the edge.
gasche
CC BY-SA 3.0
2012-04-07T10:24:39.567Z
PS: looking back at the last threads in pl.programming-lang, it seems my "9 out of 10" was more a sign of reacting on an impulse than of reasonable quantitative data. While there were a stream of closed or downvoted-to-hell topics recently, it's not true that a majority of topics ends this way. Still, I think the point about abuse of "is it exactly the perfect place to discuss this or this" meta-concerns stands, especially in the face of how newcomers whose questions are criticized may interpret it.
gasche
CC BY-SA 3.0
2012-04-07T13:51:09.383Z
@gasche I think the objections were not on theoretical but on research-level.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2012-04-07T14:05:12.823Z
This is my first question on this board - I didn't think "regular" programmers on StackOverflow would be able to answer a highly theoretical question. I'm sorry you find my form inappropriate - I was merely trying to explain my own point of view and the arguments I had already heard, to start of the discussion; I was not trying to color your opinion, nor was I fishing for any particular result. -4 just for that. Wow. I will stick to StackOverflow from now, and I apologize for wasting your time with my obvious stupidity and blatant rudeness.
mindplay.dk
CC BY-SA 3.0
2012-04-07T20:48:12.997Z
I wasn't sure if it should be closed: hence my question. If I thought it was an obvious close I would have done so. and indeed, I left it open while waiting to see what others would say. I think the -3 for this is harsh
Suresh Venkat
CC BY-SA 3.0
2012-04-11T17:09:31.983Z
@Uday "Generally, you throw an exception when it is not possible to resume, or it is meaningless to resume, or it is unsafe to resume" - precisely, but what do you do when it _may_ be safe to resume? That's the thinking that lead me to this idea.
mindplay.dk
CC BY-SA 3.0
2012-04-12T11:01:54.250Z
@mindplay.dk.  When it is safe to resume, I would say you should *resume*; not bother with throwing an exception.  This whole idea of throwing an exception and asking the handler to re-enter seems completely backwards to me.  I don't see any rationale for all this back-and-forth oscillation.
Uday Reddy
CC BY-SA 3.0
2012-04-25T17:55:31.803Z
@Uday the point is, you can't always definitively make that decision in your component for any consumer - and this allows the consumer of your component to make the decision. Of course you could introduce a flag in your component, indicating whether to throw or not under certain conditions - but that doesn't enable the consumer to log the problems. You could maintain a list of possible problems and rely on the consumer to check that list for problems after a call, but that introduces more state. So I think there is a case for something like this.
mindplay.dk
CC BY-SA 3.0
2012-04-25T19:33:14.630Z
@mindplay.dk.  Ok, I accept that there is room for debate here.
Uday Reddy
CC BY-SA 3.0
2012-04-26T17:55:50.410Z
Actually, I just thought of a technique that does solve the problem I pointed out: add an optional argument with a callback (closure / anonymous function) - and this will give the consumer a chance to respond to warnings during iteration; allow the callback to return true/false, indicating to the component whether or not it's meaningful to continue. This would provide almost identical program flow/control for most cases. So after that whole debate, maybe I'm changing my mind ;-)
mindplay.dk
<pl.programming-languages><language-design>
Why isn't it possible to recover/resume after an Exception?
mindplay.dk
# Why isn't it possible to recover/resume after an Exception?

(Asked by: username_0 on 2012-04-06)

I know that Exceptions as a means of flow-control is generally frowned upon.

But in my opinion, Exceptions have little value short of the flow-control aspect - after all, if you didn't want the program to continue, you could just output an error-message an terminate the program.

Exceptions, on the other hand, provide a means of reporting errors "locally", allowing a service/component to fail, and a consumer to handle the failure - and regardless of how you look at that, it is a means of controlling the flow of the program.

So here's my question - over the years, I have frequently wondered, why isn't it possible to *resume* execution after an exception is thrown?

Now, you wouldn't want to allow any consumer to resume after an Exception thrown by any other component, as that component was probably not designed to resume after a throw-statement, which would lead to unpredictable results.

So let's say there's a supertype of Exception called Interrupt, that allows this behavior. An Interrupt would behave just like an Exception in every respect, except that by throwing an Interrupt, you indicate that the component is ready and able to resume execution after the throw-statement, and that the stack needs to be preserved either until (A) the Interrupt has been handled, or (B) the program exits with an error-message.

Let's say we add a new "resume" statement to the language, to be used inside a traditional "catch" block - if you catch an Interrupt, and issue a "resume" statement, control would return to the point from where the Interrupt was originally thrown, and execution would continue from the next statement.

I've presented this idea in other circles, and I'm met with a lot of resistance, but no clear argument as to why this is not a good idea.

To me, it seems like a natural extension of the idea of exceptions - there are plenty of cases where this could be useful, for example while enumerating a sequence, e.g. in a function that "yields" one result at a time; an unexpected condition could occur while producing one of these results, and you may want the *calling* code to decide whether or not it makes sense to continue producing more results.

An exception does not allow for that.

Let's say this function throws an interrupt instead - if so, the calling code now has a chance to look at that and decide whether to resume execution (as if the exception never occurred) and produce more results, perhaps log the condition and then resume, or perhaps throw an exception, or perhaps re-throw the interrupt in case it can be handled up-stream.

I'm sure I'm not the first person to have this idea, but I would like to understand why this isn't feasible or why it's not a good idea.

(PS: I'm a programmer, not a scientist, so go easy on me.)

**Tags:** pl.programming-languages, language-design
> **Comments:**
> **username_1**: I'm inclined to disagree with the premise of your question. Exceptions are a means of control-flow manipulation, that's the whole point of exceptions. More precisely, they are a form of non-local 'jump' where the target of the jump (the place the program jumps to) is dynamically bound. In some contexts (e.g. Java or C++) it's considered bad style to use this non-local jumping for anything other than handling of error conditions that are not locally resolvable. But that's mostly because in these contexts exceptions are slow, not because of some fundamental restriction of exceptions.  
> **username_1**: Resumable exceptions have been investigated (e.g. they were discussed for C++), but they are hard to implement, they unconstrained use leads to badly structured programs,  and generally not considered worthwhile.  
> **username_2**: @MartinBerger  It seems to me that this should be migrated to cs.SE - thoughts ?  
> **username_1**: @Suresh. I have no objections, given the original question, although there are some interesting theoretical questions about resumable exceptions.  
> **username_3**: Well, I don't understand the question.  If the component is able to resume after the point where the error arose, why does it bother to raise an exception at all?  Generally, you throw an exception when it is not possible to resume, or it is meaningless to resume, or it is unsafe to resume.  
> **username_4**: @SureshVenkat The question is a bit rambling and could use some tightening up (mindplay.dk: this reads more like a position statement, i.e. a rant, than a question), but there is a real question in here, asking for an explanation of resumable exceptions and call/cc. I say migrate away.  
> **username_5**: I'm getting a bit tired of the systematic way questions get closed here. I subscribe to the syndication stream of some tags on cstheory.stackexchange, but when I come to see a question, expecting maybe a discussion about the question, 9 times out of 10 there is instead a discussion about why this question is inappropriate and should be moved elsewhere.  
> **username_5**: I think there is something obsessive about categorizing questions in just the exact subsubforum (oh no this is not Theoretical Computer Science but Computer Science, oh maybe it's rather Software Engineering...). The boundaries of those domains are fuzzy and I think we should accept that. It would be better if people answered questions that they find interesting, moderated obvious, non-controversial mischaracterizations, but refrained from collectively closing questions that they find a bit over the edge.  
> **username_5**: PS: looking back at the last threads in pl.programming-lang, it seems my "9 out of 10" was more a sign of reacting on an impulse than of reasonable quantitative data. While there were a stream of closed or downvoted-to-hell topics recently, it's not true that a majority of topics ends this way. Still, I think the point about abuse of "is it exactly the perfect place to discuss this or this" meta-concerns stands, especially in the face of how newcomers whose questions are criticized may interpret it.  
> **username_4**: @gasche I think the objections were not on theoretical but on research-level.  
> **username_0**: This is my first question on this board - I didn't think "regular" programmers on StackOverflow would be able to answer a highly theoretical question. I'm sorry you find my form inappropriate - I was merely trying to explain my own point of view and the arguments I had already heard, to start of the discussion; I was not trying to color your opinion, nor was I fishing for any particular result. -4 just for that. Wow. I will stick to StackOverflow from now, and I apologize for wasting your time with my obvious stupidity and blatant rudeness.  
> **username_2**: I wasn't sure if it should be closed: hence my question. If I thought it was an obvious close I would have done so. and indeed, I left it open while waiting to see what others would say. I think the -3 for this is harsh  
> **username_0**: @Uday "Generally, you throw an exception when it is not possible to resume, or it is meaningless to resume, or it is unsafe to resume" - precisely, but what do you do when it _may_ be safe to resume? That's the thinking that lead me to this idea.  
> **username_3**: @mindplay.dk.  When it is safe to resume, I would say you should *resume*; not bother with throwing an exception.  This whole idea of throwing an exception and asking the handler to re-enter seems completely backwards to me.  I don't see any rationale for all this back-and-forth oscillation.  
> **username_0**: @Uday the point is, you can't always definitively make that decision in your component for any consumer - and this allows the consumer of your component to make the decision. Of course you could introduce a flag in your component, indicating whether to throw or not under certain conditions - but that doesn't enable the consumer to log the problems. You could maintain a list of possible problems and rely on the consumer to check that list for problems after a call, but that introduces more state. So I think there is a case for something like this.  
> **username_3**: @mindplay.dk.  Ok, I accept that there is room for debate here.  
> **username_0**: Actually, I just thought of a technique that does solve the problem I pointed out: add an optional argument with a callback (closure / anonymous function) - and this will give the consumer a chance to respond to warnings during iteration; allow the callback to return true/false, indicating to the component whether or not it's meaningful to continue. This would provide almost identical program flow/control for most cases. So after that whole debate, maybe I'm changing my mind ;-)  

---

## 3 answers

### Answer by username_5 on 2012-04-07. Score: 18 | Accepted answer

"Resumable exceptions" are indeed a well-known idea in some programming language circles. In particular, Common Lisp has had resumable exceptions for a long time (so they are really not confined to research language; Common Lisp could be considered "mainstream", it has been widely available and relatively widely used for a long time).

For a discussion of resumable (or "restartable") exceptions, see for example [this blog post](http://axisofeval.blogspot.fr/2012/01/restartable-exceptions.html) by Manuel Simoni, which links to [this dylan mailing-list post](https://groups.google.com/forum/?fromgroups#!topic/comp.lang.dylan/gszO7d7BAok) by Chris Double and the following Lambda-the-Ultimate discussion: [Common Lisp exception handling](http://lambda-the-ultimate.org/node/1544).

You made the insightful guess, that resumable exceptions are not a good idea in all contexts. They can make resource handling harder and more generally anything related to side-effects must be considered very carefully when you add new control-flow entry points to a block of code.

It is possible for the exception raising code to decide on whether it should be resumable or not. This is natural if you see resumable exceptions as a combination of usual exceptions and continuations: you raise an exception and, in the attached data, decide whether or not to include a continuation to the rest of the computation; the handler then decide whether or not to invoke that continuation, that is "resume" the exception.

Effect handlers (`try..catch` block, `using`-like resource handler assuming lexical lifetime) can get confused if you re-enter the computation. Combining handlers and rich control flow is difficult and gave way to a lot of different approaches in the Lisp/Scheme communities (keywords: `dynamic-wind`, `unwind-protect`). You are certainly adding non-trivial complexity to the language.

I speak of "effect handlers" because, once you have such rich forms of control flow, you get very close to the ability of presenting arbitrary effects (exceptions, backtracking, but also logging, mutable state and input/output) on top of it. See for example Andrej Bauer and Matija Pretnar's work on [Eff](http://math.andrej.com/2012/03/08/programming-with-algebraic-effects-and-handlers/) a language based on such "effect handlers".

> **Comments:**
> **username_0**: Thank you so much for elaborating on this. This board needs more people like you.  
> **username_3**: So, the handler than has to fix the state so that the program can resume from where it broke.  That seems like a tall order.  Are there good examples of such handlers?  
> **username_0**: @Uday no, I don't think that's expected, perhaps not even possible? that's why I proposed that interrupts be a subtype of exceptions, and that only interrupts can be resumed. The handler has to decide whether it's safe to resume or not, and the throwing code should throw an interrupt (as opposed to an exception) only if it's own internal state is still valid and it is able to continue. If you could resume after just any exception, the results would be entirely unpredictable.  
> **username_5**: @Uday the common example is interactive program development; you have a running system that suddenly gets in an error state for some reason (probably a bug), and the exception handler is the debugger, a kind of REPL that has information about where in the program the error occurred *and* the possibility to resume the program at this point, or at the start of any enclosing function call. So you look at the code, look at the variable states, makes a few change, decide from where it's safe to continue, and voilà, your app continues running without having to be restarted.  
> **username_9**: A better link to Eff is http://math.andrej.com/eff/. I think we need some video tutorials about Eff, don't you?  
> **username_5**: Sorry to be nitpicking, @Andrej, but the page I linked to refers to the one you proposed, while the reverse is only indirectly true, and the one I gave has the interesting discussion with Arnaud that the other lacks. Finally, I personally have a strong dislike for video tutorials; videos are much too inefficient to consume for the reader and my plate is already full so I never watch a video online. Having videos as a complement may help you reach different audiences, but I don't remember meeting someone that preferred them.  
> **username_5**: @Andrej What I would personally like is a document that would present the relation between the practical aspects of Eff and the underlying theory, for someone that is familiar with type systems but not the algebraic effect literature. And more blog posts about the type system design, which has currently been swept under the rug from "we have no types" to "we have ML types". I think the hesitation, choices and rationale are interesting to hobby language designers, and the effect systems you must be contemplating certainly have their lot of hesitations.  
> **username_9**: Well, I am not sure why you think we swept the type system under the rug. We first had none, so we couldn't sweep it under the rug, and now we have one, and it is described in the paper. Perhaps you would like us to also explain how type inference works (rather than type checking)? This is completely standard and would get thrown out by a referee. But I agree, perhaps a technical report with more details would help. Or you could read the source code :-)  
> **username_9**: It is true we have not explained how types are to be interpreted in the denotational semantics, though. This is also "standard" to about 200 people. It would deserve an explanation.  
> **username_5**: Sorry for being unclear, I did not mean that your current explanation of types is not problematic; only that once you had no types and didn't see how to get them, and now you have a type system that you describe as a finished, done deal, and I have not seen explanations of what seemed problematic, how you solved it -- or not -- by making which choices, and if you plan to evolve it, why, and in which direction. The paper gave me the impression that the type system was mentioned, but not really discussed; indeed the focus was on the dynamic semantics and concrete examples -- which is fine.  
> **username_9**: We did not have a type system because we did not think about it at first. But we always knew it was going to exist. Now it exists. It is going in the direction of an efect system as we speak.  
> **username_10**: The problem with resource management and continuations is tied to "dynamic-unwind", which might be problematic. The difference in Common Lisp is that "handler-bind" establishes handlers that run in the context of the exception being thrown, thus not unwinding the stack. I think you already know it, but maybe this should be made explicit in the answer.  

---

### Answer by username_6 on 2012-04-11. Score: 4

Regarding gasche's answer - it's true that "you are certainly adding non-trivial complexity to the language", but it's important to keep in mind that in Common Lisp and related languages, conditions are *orthogonal to control flow*. The core of condition handling is merely a pattern for looking up handler functions, and does not in any way alter existing or add new control flow powers to the language. See this sketch of a "condition system" in JS:

<https://groups.google.com/forum/?fromgroups#!msg/ll-next/mlixSOPwc-c/iQ-xPd-kIjEJ>

> **Comments:**
> **username_3**: I am really glad to see this clarification.  So, the Common Lisp condition system decouples exception throwing (meaning, nonlocal-exits) from condition handling.  It seems wrong to characterize it as "resumable exceptions".  
> **username_6**: Right. In CL you have primitives for nonlocal exits (confusingly called [`throw`](http://www.lispworks.com/documentation/lw50/CLHS/Body/s_throw.htm) and [`catch`](http://www.lispworks.com/documentation/lw50/CLHS/Body/s_catch.htm)), and then you have the orthogonal condition system of [`signal`](http://www.lispworks.com/documentation/lw50/CLHS/Body/f_signal.htm) and [`handler-bind`](http://www.lispworks.com/documentation/lw50/CLHS/Body/m_handle.htm).  
> **username_6**: [`handler-case`](http://www.lispworks.com/documentation/lw50/CLHS/Body/m_hand_1.htm) which comes closest to Java's try/catch is actually a combination of the two systems (see the **Notes** section; `block`, `return-from`, and `tagbody` are [variations](http://home.pipeline.com/~hbaker1/MetaCircular.html) on `throw` and `catch`) -- making the point that Java and similar languages conflate condition handling and control.  

---

### Answer by username_7 on 2015-06-03. Score: 0

> e.g. in a function that "yields" one result at a time; an unexpected condition could occur while producing one of these results, and you may want the calling code to decide whether or not it makes sense to continue producing more results

I think you are describing coroutines a la <http://wla.berkeley.edu/~cs61a/fa11/lectures/streams.html#coroutines>

> **Comments:**
> **username_8**: Could you elaborate on your answer and why you think that this is the case?  

---

