Re: Better error handling for guile

[Jim Blandy <jimb@red-bean.com>]

To dig up an old thread:

Maciej wrote:
> I have started on some code to allow this; specifically, so far I
> have written a version of scm_eval which will print the same nicely
> formatted messages in case of error that the Guile repl would, and
> allow backtraces;

Mikael wrote:
> I don't understand what you want to do.  I don't think that `eval' is
> the right place for error reporting code.  It seems more reasonable
> that this is associated with the repl loop or the error handler of the
> application.
>
> Could you please clarify?

Maciej wrote:
> Well, the application in question does not have a repl loop, but does
> need to call bits of Scheme code in response to X events. In
> particular, it may need to either call a procedure or evaluate a
> string directly from the C code. When this happens I need errors to be
> reported in the nicer format, and control to return to the point where
> the evaluation was being attempted. I think other applications will
> need to do similar things - for example, a spreadsheet that uses Guile
> for it's macro langauge will likely want nice error reporting but
> probably does [not] invoke a repl when evaluating a macro.


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.