[Top][All Lists]
[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 \/ \___/ \__)