Re: Line/column numbers in user supplied exception handlers

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

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

Doesn't this conflict with what you say later about only entering the
debugger when there is a REPL in operation?

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

I think you're right, but I'm worried about the risk of confusion
(including for myself) between error handling using `catch' and error
handling using `call-with-exception-handler'.  How would you delineate
the boundary between them?

    Marius> Yes, stacks should not be needed to saved explicitely, I'd
    Marius> say.

I'm not sure what you mean here.  I wouldn't want the evaluator to do
`(fluid-set! current-stack (make-stack #t))' automatically at the
start of every frame!
 
    >> - provide a debug-on-error feature.

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

Yes, you're right.  Of course, one can also imagine a Guile
application that could be set to open a window and enter the debugger
when an error occurs.  But your example will be more common, which is
sufficient motivation for providing the `call-with-exception-handler'
idiom.

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

Right; both the lazy-catch problems are solved by calling exception
handlers in place.  I just wanted to be sure that I understood what
those problems were.

    >> [...] 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.)

    Marius> Ideally, we should have both as they are two different
    Marius> things.  I also would like to push the ability to globally
    Marius> set `debug-on-error' to the user interface of error
    Marius> handling, not to the basic mechanism.

Absolutely; that's why I say `(debug-on-error #t)' rather than `(set!
debug-on-error #t)'.  In my mind, the basic mechanism is always
`(add-hook!/remove-hook! error-hook ...)', and
`call-with-exception-handler' and `debug-on-error' are built on top of
that.  Would you agree with this layering?

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

I see.  Do you think we should do this by Emacs-like condition names
-- which is just inheritance reinvented but would allow us to keep the
property that `throw' tags are symbols -- or use GOOPS?  If the
latter, should we aim to continue supporting symbol tags (which is
easy enough, by adding a `throw' method that wraps the symbol in a
symbol-exception instance), or go for a clean break with the past?

In connection with this, I've attached a class-based error
implementation that I was playing around with a while back.  I haven't
tried running it recently, so have no idea whether it works with
current CVS, but it might be useful for discussion.

        Neil

condition-case.scm
Description: class-based errors