Lambda the Ultimate

Not without radical changes: at the very least, you'd need to reify the stack somehow, and probably couldn't sustain type erasure. Basically, condition-handling in Common Lisp is a kind of extreme reflection—even moreso than what Java gives you, in some ways.

You can have type erasure and statically typed resumable exceptions. The key observation is that resumable exceptions are a lot like first-class continuations (ie, call/cc) with the extra restriction that you can throw to them only once. This means that you can type them in a type system with linear continuation variables.

EDIT: I should note that Smalltalk does quite a bit more than just resumption. Not only does it have full continuations, but you can examine the stack frame by frame, which lets you implement AOP as a library. (Whether this is a good idea is another matter, but it's worth being clear about what ST can do.)

...that on LtU, saying "you can type them in a type system with linear continuation variables" wouldn't qualify as "a radical change" relative to Java, C#... :-)

Touche!

EDIT: Though the funny thing is that linear types are seeing heavy use among PL researchers doing work on Java/C# like languages. They let you typecheck things like object usage protocols, object states, and so on. We might well see linear types in the next round of commercial language designs....

Do you really need complex machinery like stack reification?

My understanding (ok, maybe flawed) is that a condition handler can just be a closure bound to a global (/special) variable, so that the place where the error occurs can find the handler. It will then call the handler, passing in the error condition (this, I'd say, is like a normal function call, with the usual stack behavior). The handler will do what it takes (maybe invoke the whole interactive debugger) and at some point return with a value that tell the restart what to do (throw, use nil as value, use 0 as value...).

While exceptions (throw) need special stack behavior, I don't think that restarts do in general, as there is no real "longjmp", in C terms.

I'm not entirely sure if this is the same thing as the uses of resumeable exceptions discussed on this page, but here is some code I've occassionally used in Tcl for debugging exceptions. Basically, instead of throwing an error, it simply calls the debug procedure which starts a REPL at the current point of execution. You can then use Tcl's introspection commands to move up/down the stack and examine/set variables etc. I've found it very useful on occassion. No stack reification, but it does rely on the fact that Tcl allows access to the stack at runtime via [uplevel] and [info level].

proc debug-repl {} {
    set cmd ""
    set level [expr {[info level]-1}]
    set prompt "DEBUG\[$level\]% "
    while 1 {
        puts -nonewline $prompt
        flush stdout
        gets stdin line
        append cmd $line\n
        if {[info complete $cmd]} {
            set code [catch {uplevel #$level $cmd} result]
            if {$code == 0 && [string length $result]} {
                puts stdout $result
            } elseif {$code == 3} {
                # break
                error "aborted debugger"
            } elseif {$code == 4} {
                # continue
                return
            } else {
                puts stderr $result
            }
            set prompt "DEBUG\[$level\]% "
            set cmd ""
        } else {
            set prompt "    "
        }
    }
}
proc up {} { uplevel 2 { debug-repl } }
proc down {} { return -code continue }

And to demonstrate it's use, here is a sample session using it:

% proc foo {args} {
     set a 1
     debug-repl
     puts "Resumed, a = $a, args = $args"
}

% proc bar val {
     foo $val
}

% bar 19
DEBUG[2]% info locals
args a
DEBUG[2]% up
DEBUG[1]% info locals
val
DEBUG[1]% set val
19
DEBUG[1]% down

DEBUG[2]% set a "Hello, World!"
Hello, World!
DEBUG[2]% continue
Resumed, a = Hello, World!, args = 19

You can replace the usual [error] handling capabilities to make this automatic for most errors in Tcl. It's also trivial to make this work over a socket or other channel for remote debugging.

Is this something like the debugging uses of CL resumeable exceptions?

Mary Fontana presented similar data from the TI Explorer system where resumption was found to be used for debugging only

That's quite an "only"! I would say that debugging is one of the most important activities in writing software.

In Lisp and Smalltalk debuggers are just normal programs that happen to be invoked at the point of an error and happen to call the stack-inspection functions (etc) to help show the programmer what's going on. It's no big deal to write your own debugger or debugger-like function and hook it in. This is much more elegant than putting the whole debugger into the "runtime system" black box, which typically means writing a rigid one in C.

There is also a big convenience factor for interactive use. For example, suppose your program tries to write its output to a directory that doesn't exist and that the program doesn't handle this condition.
Then it's really nice for the system to see the problem and for a 'debugger' function to offer to create the directory (or switch to another) and then continue. The ability to poke around and patch things up at runtime makes unhandled exceptions quite fluid to deal with.

People have an unfortunate tendency to ignore these basic conveniences and focus on hypothetical software-engineering mumbo-jumbo scenarios. "Oh my, what if Luke installed an exception handler that ROT13 encoded every string on the heap, then how would Jane debug her programs?" This is not the way to illumination.

Just as I wrote that my Bittorrent client 'handled' an IO Exception by printing "IO Error: [Errno 28] No space left on device" and then getting stuck. This is a case where it would have been much more helpful to leave the exception unhandled and let the system's default handler (a 'debugger' function) offer me some alternatives to aborting, like "Try again now". That's how a Common Lisp version would behave.

By wrapping a process by an observer process, that calls catch and then polls on some port for debugger input, can we get the same convenience? The problem I'd see is that catch only get's post-mortem messages, so stack inspection is not possible. Provided this can be dealt with, the advantages however would be: No abstraction violation (the other point against resumption) and no performance hit, if not wanted. But I know too little of Erlang to tell how well this works. (But I know how well it works with CL ;)

The biggest use for me is to simply "know" it's there. I'm right now popping out CL code, which may never be hardened enough to see handlers/restarts. BUT, the last time I was writing in Python (a language I learned before hearing of Common Lisp), I felt like I had to get a good idea of how the error handling would look earlier rather than later.

As this is just an anecdotal observation, it may be entirely wrong... but perhaps someone had similar thoughts.

The passage you link to refers to but does not relate the arguments for termination that convinced the C++ committee. I would appreciate more details on the experience referred to there.

I found the experience of the TI guys always dubious. My experience on the Lisp Machine is completely different. I would not want to live without that feature. The concept says that you have all kinds of restarts and error handlers in the dynamic context of your code. On signalling an error, the handler is looked up in the dynamic context. But then you don't 'jump' to the handler but you call it like a function. The handler then decides what it wants to do. For example it can present the current applicable restarts to the user. The operating system and the application can provide lots of useful restarts and the Lisp Machine did.

Typical scenarios:

- the application wants to open a file, but it is not there. Now you have various options like using another file, finding the file somewhere else, creating the file and resuming, just retrying, and so on.

- you have a suddenly a loss of network connection. You can now handle the network connection error with several options

- the compiler detects an error while you are in the midst of compiling a larger system. You could fix the error, go into a debugger, recompile the file, recompile the system, etc.

In many situations you can fix the problem and just retry the operation that signalled the error. This can save so much time.

Looks interesting, could you provide a short example of use?

To me, the most important problem in handling exceptions is to accurately distribute responsibilities between two parties - a potentially failing application code (a worker) and the handler. In many cases it might be benefitial if the handler were unaware of details of the worker, just trying to mend the environment and delegating the actual retry back to the worker. This approach is in a way similar to STM - a transaction (a worker) can 'retry', and the transaction scheduler (a handler) will mend the world for it by waiting until some variable from the read set changes, and will resume by executing the transaction again.

My intuition of Haskell is still very weak, so I cannot "see" whether your solution allows such factoring of responsibilities. Could you comment? Thanks.

Indeed, throwing an exception and being resumed by the handler is no different from the invocation of the handler as a regular function.

That's a really clever observation!

If the C++ stack had 'restart points' that it could return to after an exception, it would vastly help for modularity by reducing undesired coupling between policy and mechanism (as described in this paper).

The trick is to provide more than one resumption point (so that policies have an actual choice), to properly handle asynchronous exceptions, to do so in a manner reasonably symmetrical to the exception handling mechanisms, and to do so efficiently - where the static and runtime costs of doing so are, ideally, no more than the costs of the existing exception handling mechanisms.

It's doable! A solution is described below.

1. The 'exception handler' block executes at the top of the local stack much like a local function. Some special handling is provided to appropriately handle both the dynamic context and the ability to call more functions. This behavior is already common to commercial implementations of C++ exception handling, and so should not be problematic.
2. The exception handler can 'resume', at which point execution would unwind the stack to the appropriately labeled resumption point that is on a stack frame between the exception handler frame and the signaling event. During stack unwind, any destructors (or 'finally' blocks in Java) are called appropriately. The benefit here is to allow the policy to select a given resumption point that partially unwinds the stack (whereas one currently unwinds all the way to the exception handler).
3. The resumption point can accept a parameter in much the same way as the exception handler receives an exception. This allows resume-with-parameters.
4. the exception handler could perform any of its normal behaviors just as it does today, with leaving the exception handler block or returning from the function causing the stack to unwind all the way to the exception handler.

For syntax, it would be necessary to mark certain regions as 'restartable' such that they can be found by the exception handler in the same way the exception handler itself was located. A given restart might be selected under a number of conditions. If parameters are required for the restart, there would need to be a block associated with each restart condition prior to entering the restartable action. For symmetry, one might simply put 'restarts' on the opposite side of the 'try' block from the 'catch' blocks.

In the example, I call the resumable blocks reset, and so the try/catch duo becomes reset/try/catch. In Java, it would become reset/try/catch/finally. The behavior of a reset block is to accept the parameter it receives (if a name was specified), execute any behavior inside the following block, then pass control to the try block. When initially entering the try block, reset blocks are simply skipped.

namespace std { 
  template<typename T> class continue_with{ 
     private: T t; 
     public:  T const& value(); 
  }; 
  class signal : public exception {};
  class div_by_zero : public signal{}; 
  // the above would presumably override 'what()'
  // Assume C++ is modified to throw 'div_by_zero()' 
  //  after a division by zero error.  
}

double divide(double a, double b) {
  reset(std::continue_with<double> const& cwd) { return cwd.value(); }
  try { return a/b; }
}

double randf(double a, double b) {
  try { return a + divide(divide(rand(),RAND_MAX+1),(a-b))); }
  catch(div_by_zero const&) { resume(continue_with<double>(0.0)); }
}

The above is a trivial example, intended more to indicate syntax than anything else. If one called randf(1.0,1.0), one would get 1.0 back because the failed 'divide' throw an exception but then would 'continue with' 0.0.

One thing to note is that the resume action seems to be assuming, without testing, that the given resume type is available. Presumably there would be another exception (perhaps unresumable_exception) if this were not the case! While one could catch 'unresumable_exception' to try a variety of possible resumptions, it would be convenient to have another keyword, resumable(type) to dynamically test whether a given resumption condition is available. To be symmetrical, one might also want to add a catchable(type) to test whether a given type will be caught if thrown.

This whole approach to resumable exceptions also introduces the possibility of very cleanly handling asynchronous exceptions, which would include kill signals, timeouts, thread interrupts or alerts, alarms, etc. Basically, an asynchronous signal would itself execute much like a function at the top of the stack that throws an exception. If the interrupt needs to be fully resumable, it simply needs the correct 'reset' behavior:

class signal_kill { class ignore {}; };

void kill() {
  reset(signal_kill::ignore&) { return; }
  try { throw signal_kill(); }
}
void sure_kill() { throw signal_kill(); }

void black_knight(int hitpoints) {
  try {
    while(hitpoints > 0) {
      sleep(3000);
      // output snarky comments, swing sword
    }
  } catch(signal_kill const&) {
    --hitpoints;
    if((hitponts > 0) && resumable(signal_kill::ignore)) {
      cout << "I fight on! Tis only a flesh wound!" << endl;
      resume(signal_kill::ignore());
    }
    // if code reaches this point then black knight is dead
  }
}

void goodknight(bool bHasExcalibur, int patience, Thread* opponent) {
  // assume Thread.interrupt() will queue an event to execute in the
  // given thread where this event may be a signal 
  // (via use of asynchronous exceptions)
  while(patience-- > 0) {
    sleep(3000); // can only get one good blow in every 3 seconds
    if(bHasExcalibur) { opponent->interrupt(&sure_kill); }
    else { opponent->interrupt(&kill); }
    if(opponent->is_terminated()) {
      cout << "Good night." << endl;
      return;
    }
  }
}  

The above does ignore a few difficulties, such as receiving asynchronous interrupts while handling asynchronous interrupts, and properly catching the results. In this case it would work out well enough, though the black knight might die in the middle of saying "I fight on!" if he lost the last of his hitpoints in another asynchronous call. (Because the exception handler unwinds the stack only after resuming, the same handler would necessarily receive all of the sig_kill calls until the black_knight dies, but would be duplicated on the stack in various states of resumption.)

Anyhow, I seriously think this is workable with and reasonably symmetrical to the existing exception handling capabilities found in languages like C++, Java, and C#. As in, we could have it in an experimental version of C++ and ready for integration with whatever comes after C++0x or the next version of Java.

There is no simple/good alternative to restarts:
* when stack is unwinded
** exception safety is very difficult
** resumption is not easily possible
* when problem is clearly defined like ...NotFound/ReadOnly/Locked and solved how to continue without restarts?
** Which line within the try?
** Transaction-Rollback and Repeat? What about physical side effects?
** Compensation? For the second rocket stage?
Simple resumption behind the signal-statement is not enough, like Stroustrup says.

Can you simply delay unwinding the stack until the exception handler returns?

The programmer can chose explicitely where to retry from. Also side-effects can be explicitely compensated (see D scope statement for a convenient way to do this).