Re: Line/column numbers in user supplied exception handlers

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> >>>>> "Marius" == Marius Vollmer <address@hidden> writes:
> 
>     Marius> Neil Jerram <address@hidden> writes:
>     >> I'd like to experiment with this; what I have in mind is [...]
> 
>     Marius> Yep, I think that's a good transition strategy.
>     Marius> Ultimately, I would want the scm_ithrow to disappear
>     Marius> completely.
> 
> OK, but why?  Presumably there would always have to be a default
> handler.

Yes, true.  But I'd say that this default handler is not one that
calls scm_ithrow, it would invoke the debugger...

> The goals that I have in mind are:
> 
> - provide a way for an application to register a global error handler
>   that runs in the context of the error, (including to address the
>   problem of getting at line/column numbers)

Hmm.  Should there be only one global error handler, or a list of
them?  I think we should have a global list of error handlers that is
managed in a `dynamic scope' manner, like the dynamic wind chain.

> - provide a neater way of doing the existing stack saving (for later
>   `(debug)') and `(debug-enable 'backtrace)'

Yes, stacks should not be needed to saved explicitely, I'd say.
 
> - provide a debug-on-error feature.

Yes, but isn't that a more of a parameter of the repl?  The repl would
establish a error handler for the code it executes, and depending on
that parameter, the handler either throws back to the repl loop or
enters the debugger.

>     Marius>   - Function: call-with-exception-handler HANDLER BODY
> 
>     Marius>   Establish HANDLER as the top-most exception handler
>     Marius> while executing BODY.  If a exceptional situation arises
>     Marius> (i.e. signal-exception is called), HANDLER is invoked with
>     Marius> the object representing that exception (i.e. the object
>     Marius> passed to signal-exception).  When HANDLER returns, the
>     Marius> next handler below HANDLER is invoked.  When no more
>     Marius> handlers exist, the debugger is invoked.
> 
> This sounds a little like `(lazy-catch #t BODY HANDLER)'.  I don't
> think that's your intention, but it made me try to remember what I
> didn't like about lazy-catch, and I think it's worth summarizing
> that here.
> 
> 1. It's too lexical.  Use of lazy-catch to find out information about
>    the context in which an error occurs can be subverted by a `(catch
>    #t ...)' between it and the source of the error.

But with the error or exception handlers that we are talking about, no
change of the dynamic context takes place when invoking them, i.e.,
the dynamic wind chain is not unwound.

> [...] So a global setting like `(debug-on-error #t)' feels more
> natural to me than usage like `(call-with-exception-handler
> debug-on-error-handler BODY)'.  (Cf. Emacs Lisp, of course.)

Ideally, we should have both as they are two different things.  I also
would like to push the ability to globally set `debug-on-error' to the
user interface of error handling, not to the basic mechanism.  It is a
good example of things that are desirable that we should keep in mind.

Would the characterization of `debug-on-error' as a repl parameter
work?  I'm not entirely sure, as not all code is executed from the
repl.  But the debugger is a repl of its own, so one might argue that
it only makes good sense to enter the debugger when there is already a
repl running (so that the user is prepared for interacting with the
system).  Hmmm....

>     Marius> But, as a first step, I would propose to define
>     Marius> abstractions for the existing error objects (the lists
>     Marius> with a symbol as the first element).  That way, we could
>     Marius> improve their representation later on.
> 
> I don't follow you here; please explain.

Currently, we have the convention that errors are signalled by
throwing a four-element-list where the are certain meanings to the
elements.  This is not a flexible and clean definition of the objects
that represent exceptional conditions.  I would like to have a
hierarchy of condition objects and a clean way of defining new
objects.

>     Marius> In any case, I'd like everybody to wait until we have the
>     Marius> stable branch before introducing experimental things into
>     Marius> CVS.
> 
> Certainly.  Is the plan that the trunk will be available for
> continuing development as soon as the stable branch has been created?

Yes.