Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't think they are, unless you are talking about the few implementations of resumable exceptions. The most obvious counter-example I can think of is C++, where the stack from where the exception was thrown is unwound to the handler, i.e. it's destroyed (doubly so if the exception handler puts anything on the stack). That's also why you can't get a stacktrace from an exception in C++ unless you specifically arranged for the thrower to include that information in the exception object.


I believe exceptions are equivalent to a limited form of continuations called escape continuations where control flow can only go upwards (which is the stack unwinding). Note that this is also true of break and continue, actually, both of which can be implemented with either exceptions or escape continuations.


Even resumable exceptions are/can be much more bounded than continuations. Exceptions always respect the scope structure of the code (even though they can jump between scope levels), whereas continuations can break this arbitrarily.

In particular, in Common Lisp, restarts are only valid in the dynamic environment where they were created by restart-bind. In contrast, call/cc captures this dynamic environment and makes it available later. You can't store restarts and invoke them later the way you can with call/cc.


In continuation passing style, a compiler technique, exceptions show up quite naturally as a second continuation. The whole thing is called "Double barrelled continuation passing style".


You can get the stack trace by breaking in "throw". Maybe you meant something else.


Breakpoints on throw are triggered before unwinding (you are effectively setting a breakpoint on the function called to unwind).

You simply cannot create a stack trace from within a C++ exception handler because that state is gone. Hence my argument that exceptions are not a continuation, there is nothing to continue.


All true. But also a bit of a diversion, because the information you wanted "from within" the exception handler is available at the throw site. Ergo, if you're trying to get it from within the handler, you're just trying to get it from the wrong place.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: