guile-devel
[Top][All Lists]
Advanced

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

Re: Line/column numbers in user supplied exception handlers


From: Marius Vollmer
Subject: Re: Line/column numbers in user supplied exception handlers
Date: 06 Jul 2001 01:13:04 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

Neil Jerram <address@hidden> writes:

> I'd like to experiment with this; what I have in mind is, before
> `scm_ithrow (key, arg_list, 1);' in scm_error:
> 
>     scm_c_run_hook (scm_error_hook, scm_cons (key, arg_list));
> 
> Then, just as you say, one of the hook procedures can exit non-locally
> if it wants to; but if none of them do, the scm_ithrow will happen.

Yep, I think that's a good transition strategy.  Ultimately, I would
want the scm_ithrow to disappear completely.

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

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


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

  - Function: call-with-exception-handler HANDLER BODY

  Establish HANDLER as the top-most exception handler while executing
  BODY.  If a exceptional situation arises (i.e. signal-exception is
  called), HANDLER is invoked with the object representing that
  exception (i.e. the object passed to signal-exception).  When
  HANDLER returns, the next handler below HANDLER is invoked.  When no
  more handlers exist, the debugger is invoked.


But, as a first step, I would propose to define abstractions for the
existing error objects (the lists with a symbol as the first element).
That way, we could improve their representation later on.

In any case, I'd like everybody to wait until we have the stable
branch before introducing experimental things into CVS.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]