Re: Line/column numbers in user supplied exception handlers

[Neil Jerram]

>>>>> "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.

    Marius> Together with the hook we should have a reasonable
    Marius> high-level way for specifying error handlers, and to treat
    Marius> the objects that represent error conditions.  (There is a
    Marius> withdrawn SRFI about this, right?)

    Marius> Or, in other words, I would like to first define the goal
    Marius> more clearly that we want to reach when changing the error
    Marius> handling before experimenting with implementational
    Marius> issues.

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)

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

- provide a debug-on-error feature.

    Marius> Off the top of my head, I could image providing something
    Marius> like this

    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.

2. Dynamic context is "wrong" - i.e. not that of the point where the
   error occurred.

I think there's a difference between the kind of specific error
handling that you can do with `catch' and the kind of error handling
that you would use a scm_error_hook for; in my view the latter is more
global.  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> 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.

    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?

        Neil