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



mdj@nada.kth.se writes:
> Maciej Stachowiak <mstachow@mit.edu> writes:
> 
> > 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;
> 
> 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?
> 

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 invoke a repl when evaluating a macro.


> > I think versions of gh_eval_str, gh_apply and gh_call[0-3] that do
> > nice error handling would be a good addition to Guile.
> 
> If the user has installed an error handler the handler can take care
> of error reporting for all of the above functions.
> 

I will look into this. The main guile REPL seems to do this by
establishing both a lazy catch and a conventional catch around the
relevant block of code, and saving the stack before evaluating. My
understanding of the debugging code is fairly shallow, so I'm not sure
if it is truly necessary to do this, or if there is a simpler way;
perhaps the code you posted will prove enlightening.

However, with the need to set up two catches (and the two associated
body functions), coding nice error reporting is a pain, whereas it's
quite often what the app wants to do, rather than the simplified error
reporting or imeediate exit that are the currently accessible options.

So I guess a brief summary would be that I want to


> > Optimally, I'd like to get this in for the next release.
> 
> We're always open for including new code if we feel that it's a good
> solution and in line with future Guile development.  Sometimes,
> however, knowing that this is the case requires thinking, which
> requires time, which is not always immediately available.
> 

I understand that; I'm certainly open to advice on the best way to
implement what I want to do, and wether anything like it even belongs
in Guile :-)

> > * Top-level expressions which are not lists do not have source
> > properties. This means that if I have a top-level expression like:
> > 
> > some-silly-variable-reference
> > 
> > in a file and I then load that file, the error message will be
> > prefixed with "ERROR:" instead of the filename and line and column
> > numbers, as would be the case for any other error in a file.
> 
> As you point out, the reason is that source properties only are
> attached to pairs in the source code.
> 
> Since this is a limitation in the basic source information code, I
> suggest that you simply ignore the problem until (and if) someone
> solves it on the basic level.
> 

That was mostly my intention; I wanted to bring it up in case I was
missing something.

> 
> > * On the other hand, the input file property appears to be there and
> > is used for the standard input, so you get errors prefixed with
> > "standard input:0:0:" instead of "ERROR:" for non-atomic expressions.
> 
> While this may not be the nicest form of information to the user, I
> don't think it is wrong that the source properties tell the accurate
> origin of the source.  The right solution is probably to handle this
> in the display routines (printing just ERROR when the file name is
> "standard input").
> 

I don't think this is a problem in itself either, the behavior just
happens to differ from what the Guile interpreter does when running
interactively (it displays "ERROR:" for errors from the standard
input, with no obvious [to me] attempts to circumvent the error
displaying code to achieve this).

> > * It's currently necessary to cons a list for each expression
> > evaluated to make scm_m_start_stack happy. This would surely slow
> > things down in batch mode.
> > 
> > * Using scm_m_start_stack does not seem to generalize easily to doing
> > a call instead of an eval, e.g. gh_call0().
> 
> I've now separated the guts of scm_m_start_stack (which was never
> meant to be used from C) into a function:
> 
>   SCM scm_start_stack (SCM id, SCM exp, SCM env)
> 
> BTW, have you noticed the function scm_internal_stack_catch?  That's
> the function to use when writing an application error handler.
> 

No, I haven't. Perhaps I have been inflicting unnecessary pain on
myself. I will look into how things work in light of this function.

Thanks for all your help.

 - Maciej