Hacker News Reader

Comment by useerup | Hacker News Reader

Exception handlers are continuations.

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.

I'm guessing you're trying to equate

  try{
    foo()
  }catch(Exception e){
    bar(e)
  }
  
  void foo() {
    throw new exception();
  }

with

  (bar (call/cc foo))

  (defun foo (cont)
    (cont (make-exception))

However, this ignores most details of the problem. In fact, (re-entrant) continuations and exceptions can't be mixed in the same language: Common Lisp has not adopted `call/cc` for one because it's impossible or at least much harder to implement `unwind-protect` (`finally`) in the presence of `call/cc` [0].

The major difference is that continuations allow you to do this:

  (defparam *global*)
  (defparam *shadow-list* (list))
  (defun foo (cont)
    (setf *global* cont))
  (with-open-file (f "~/file.log")
    (loop
      for line = (read-line stream nil 'eof)
      until (eq line 'eof)
      collect (cons line (call/cc foo)))

  (*global* *shadow-list*)
  (*global* *shadow-list*) ;; what is the state of the file here? what if there was an exception reading from the file?

[0] https://groups.google.com/g/comp.lang.lisp/c/1Ggl_BUi3Yg/m/V...

Naw, it's not impossible; you just use dynamic-wind. But to me this has a bit of the spirit of "Now, you have two problems..."

Well, dynamic-wind itself does not do what unwind-protect does. You have to manually "save/resume" the dynamic environment with the after/before clauses of dynamic-wind.

To be fair, it's probably relatively easy to use dynamic-wind to raise some runtime error when trying to resume the continuation after the original context "ended".

It doesn't, no, but yes, that was my thought: write a version of with-open-file implemented in terms of dynamic-wind that raises a runtime error if you try to reenter. Better hope people are using call/cc for exception handling and not threading though...

Pitman's comments on this are in http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuat..., Sitaram's response is at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.79.3..., and Pitman's final response is at http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuat....

I have seen exceptions implemented with setjmp/longjmp, and I have seen continuations implemented with setjmp/longjmp/memcpy. So they are definitely related, but equivalent? Or are you saying something else?

Reply on news.ycombinator.com