[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error Continuations

This page is part of the web mail archives of SRFI 34 from before July 7th, 2015. The new archives for SRFI 34 contain all messages, not just those from before July 7th, 2015.

   Date: Thu, 25 Jul 2002 09:33:24 -0700
   From: "Scott G. Miller" <scgmille@xxxxxxxxxxxxxxxxxx>

   [In SISC the handler is passed a continuation as well as a condition.]

   This, combined with support for inspecting continuations, allows for 
   powerful debugging capabilities, and more flexibility in the
   control of program flow when errors occur.

Restarting the program from a handler is the subject for the third companion
SRFI in the list in SRFI 34's rationale:

 - a SRFI specifying how computations may be resumed after an exception
   is raised.

Three simultaneous SRFIs seemed like enough so we didn't submit a restart
SRFI as well.  SRFIs 34, 35, and 36 are useful without restarts and restarts
can easily be implemented using them, so it doesn't seem like a huge hole.

The problem with passing a single continuation to the handler is that
there may be more than one place, or more than one way, to restart the
program.  The handler needs to be able to find all of the possible
ways to restart and have some way of choosing between them.

As you say, writing a portable debugger requires a lot more than just getting
the relevent continuation when an error occurs.  I would expect that a SRFI
whose intent was to support such things would a way to capture continuations,
or at least inspectable versions of them, in a variety of circumstances.