guile-user
[Top][All Lists]
Advanced

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

Re: Getting scheme error informations when running scheme code from C


From: Christian Mauduit
Subject: Re: Getting scheme error informations when running scheme code from C
Date: Sat, 10 Sep 2005 23:36:17 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050803)

Alan Grover a écrit :
> My comments are for Guile version 1.6.4.
> 
> To get a backtrace, you want something that does the same thing as the
> --debug option. However:
> "Using the debugging evaluator will give you better error messages but
> it will slow down execution."
> So, you don't want it in production-code.
> 
> I believe this will turn on the debug-evaluator at run-time (so the
> documentation implies):
>       (debug-enable 'debug)
> Hope that causes a stack-trace for you. See "Configuration, Features and
> Runtime Options" in the documentation, subsection "Debugger Options".
mmm, OK I see, indeed using:

(debug-enable 'debug)
(debug-enable 'backtrace)

gave me much more detailed output, thanks for the tip.

> Have you considered using "catch" to catch errors (or "lazy-catch")? You
> could wrap your scheme code in a "catch", or use scm_catch. Section "How
> to Handle Errors in C Code" has some hints. Lazy-catch lets you capture
> the stack.
> 
> I don't see a mechanism for adding a "catch" for primitive-load. The
> empty documentation for "REPL Hooks" is suggestive. So, use scm_catch,
> or "eval" something like:
>       (catch #t
>               (lambda () (primitive-load ...))
>               (lambda (key . args) (deal with error here)))
> (of course, you could add a function that does this to the top-level and
> just call it.)
> 
> You may also find the section "Debugging Infrastructure" interesting. It
> talks about decoding the stack, and limiting the backtrace.
> 
> 
> Lazy-catch will let you examine the stack as it exists at the time of
> the throw/exception. You could dump the stack with "display-backtrace"
> or programatically try to find the relevant stack-frame (an interesting
> problem since tail calls may-not generate a frame). See section
> "Examining the Stack".
Well, using lazy-catch and a handler with the line:

(display-backtrace (make-stack #t) some-user-string-output-port)

actually got me very close from solving my problem completely. The only
point is that the stack I obtain contains many useless things (such as
the actual functions I'm using within the error handler, which are
useless...) so I get a garbaged output. I guess there's some way to get
rid of this by passing cryptic arguments to make-stack. BTW trying to
handle the object returned by make-stack and produce a string output "by
hand" from it sounded awfully hairy to me. Wee.

If I get an elegant solution to my problem, I'll try to package it and
make a short text on the question, by searching the web I found out that
I'm not the only one to wish to handle his errors himself, but the
tutorial does not seem to be written yet 8-)

Have a nice day and thanks for your help,

Christian.

-- 
Christian Mauduit <address@hidden>     __/\__ ___
                                        \~/ ~/(`_ \   ___
http://www.ufoot.org/                   /_o _\   \ \_/ _ \_
http://www.ufoot.org/gnupg.pub            \/      \___/ \__)




reply via email to

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