Does all exception handling have to use dynamic lookup?

Question

According to the "Section 3 Summary" for Coursera's "Programming Languages, Part A" course (by Dan Grossman of the University of Washington):

But you have seen one feature that is more like dynamic scope than lexical scope: exception handling. When an exception is raised, evaluation has to “look up” which handle expression should be evaluated. This “look up” is done using the dynamic call stack, with no regard for the lexical structure of the program.

I think the writer is talking about Standard ML, but C++ seems also to do the same thing. Do all languages do "exception handling" with such dynamic lookups?

Answer 1

Yes, that is how exception handling works.

FWIW, exception handling as we understand it today was invented in the CLU language in the 70s and developed further in ML in the early 80s. From those it spread into other languages like C++, mostly only with variations on how exceptions are constructed and matched.

It is also worth noting that exception handling is just a special case of a more recently invented generalised mechanism called effect handlers, which is much richer and can express all sorts of other control structure, like coroutines, generators, async/await, even backtracking and more. Its main addition over exception handling is that a handler can resume the throwing computation, passing back a value. Like exception handling all its applications crucially rely on the dynamic extent of handlers.

Answer 2

(Revised answer)

Do all languages do "exception handling" with such dynamic lookups?

If you define exception handling to always mean: Unwind the call-stack and look for an exception handler, then the resemblance is unavoidable. But there is a difference between "like dynamic scope" and "with dynamic scope".

Incidentally Standard ML allows for locally defined exceptions and does not offer introspection on values, including exceptions. For example, the following program does not type check:

fun foo () =
    let exception Foo
    in bar () handle Foo => true
                   | _   => false
    end
and bar () = raise Foo

It does enforce a control flow that is similar to the identifier lookup mechanism for dynamic scoping, but handlers do not inherit the scope of named exceptions to match against from their parent handler. So I don't think it is reasonable to say that Standard ML exceptions even resemble dynamic scope that much. Common features in dynamic programming languages like exceptions inheriting from a base class and runtime type annotations make the analogy stronger.

There are other error handling systems that pass control flow elsewhere than upwards in the call-stack. For example, you could think of to Erlang's process linking as an exception handling mechanism where multiple linked processes may handle the event of a process exiting. Here, the control flow only vaguely resembles that of dynamic scoping, since there isn't a strict hierarchy, but a graph, of exception handlers. It also isn't very close to any common definition of exceptions, even though a process crashing is exceptional.

Answer 3

Consider a piece of code like this:

fun add (a, b) = a + b
fun double a = add (a, b)
val _ = double 10

When add returns, it returns control to the next function call on the call stack, namely double. I don't think it's meaningful to think of this as "dynamic scope"; rather, this is just the basic functionality that the call stack provides by virtue of being a call stack.

Similarly, when add raises an exception (such as Overflow), it also returns control to double. (As it happens, of course, double doesn't handle any exceptions, so it implicitly re-raises all exceptions to its own caller.) Dr. Grossman apparently has in mind that a Standard ML implementation would keep a dynamically-locally-scoped record of the innermost handler, so that when you raise an exception, the control jumps directly to a handler instead of passing via double; but that's just an optimization. The behavior is no different than in a Standard ML implementation where the compiled code for double handles propagating exceptions from add.

I think the key point, in both cases, is that add itself cannot "look up" information from its calling context. Rather, add merely exits, restoring control to its calling context.