This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Better error handling for guile



jimb@red-bean.com writes:
> 
> First off, let me say that Guile's error handling is not very
> consistent.  I certainly can't fault you for not being able to see the
> "correct" pattern by looking at the existing code.
> 
> But Mikael's actually correct about this (although he may not have
> stated it clearly).  There is a correct way to do error handling;
> Guile's not doing it consistently, and your proposal isn't really the
> right thing either.
> 
> You are correct that applications like SCWM or spreadsheets don't have
> REPL's, and we certainly don't want to force them to have some kind of
> artificial REPL.  But they all have some kind of top-level loop.  In
> the command-line Guile interpreter, it's the REPL.  In SCWM or a
> spreadsheet, it's the event-processing loop.
> 
> In all of those cases, you ought to be able to provide the error
> handling you want in a modular way, by providing a function that
> establishes an error handler for a given dynamic context, and then
> going whatever you please in that context.
> 
> Hacking scm_eval, gh_eval_str, gh_apply, and gh_call seems like very
> much the wrong way to do this, because doing so would take control out
> of the hands of the user.
> 
> Putting error handling in the REPL is not right.  Putting error
> handling in the functions is not right.  Error handling is a separate,
> modular thing, which you should be able to plug in where you need it.
> Just inside the REPL or event loop is usually a good place.
> 
> Have you taken the time to really grok what's going on in throw.c,
> especially scm_internal_catch?  I think if you do, you'll see that
> there's a much nicer way to handle all this.

Well, for the record, here is what I ended up doing in scwm. For all
callbacks that happen from the event loop, I set up a
scm_internal_stack_catch (or scm_internal_stack_cwdr, something I
hacked up myself which does a stack-saving catch and also installs a
new dynamic root, but I'd be glad to send it in if you think it is
generally useful) which initializes the stack, and use an error
handler that retrieves the last stack and displays a friendly error
message. I don't think registering a top-level error handler of some
kind around the event loop is the right thing for me, because whenever
a callback fails, control needs to return to right after it so that
the proper cleanup can take place, and callbacks are launched from
many places in the code.

What I think the right thing would be, is actually a pretty simple
change to what guile does now: add a gh_stack_default_handler (or some
such) which can be used with gh_eval_str_with_stack_handler which
prints a nice error message along the lines of what the repl does, and
make gh_eval_str_with_stack_handler and gh_stack_catch actually work,
and encourage their use. I am no longer certain if things like
gh_apply_with_stack_handler would be a useful abstraction, but a
similar (but differently named) thing is certainly very useful for
scwm specifically.

 - Maciej