Neil Jerram <[EMAIL PROTECTED]> writes:
>
> an example?
(c-lazy-catch #t
(lambda ()
(mucho hairy data download using http, including continuations
to suspend))
(lambda args
(print-message "%s and %s went wrong" ...)
;; continue on connection or http protocol problems (including
;; http timeout), throw full error otherwise
(if (not (or (eq? 'http (first args)) ;; my errors
(gethost-error-try-again? args) ;; gethost errors
(system-error-econn? args))) ;; ECONNREFUSED
(apply throw args))))
The idea is the handler does some cleanup (print a message in this
case) and then makes a decision about continuing or dying. If it's
fatal then re-throw, and in that throw I'm wanting a full backtrace.
If this was a plain `catch' then the re-throw loses the backtrace, and
if it was a lazy-catch then you're not allowed to return, hence my
c-lazy-catch which is a combination. The implementation isn't
super-efficient,
;; lazy-catch, but with HANDLER allowed to return
(define-public (c-lazy-catch key thunk handler)
(catch 'c-lazy-catch
(lambda ()
(lazy-catch key thunk
(lambda args
(throw 'c-lazy-catch (apply handler args)))))
(lambda (key val)
val)))
I'm not sure how typical this is. It seems a reasonable desire, but
maybe there's a better way to do it. I've fiddled about a bit with my
overall error trap structure, from trapping each call to now a higher
level overall catch.
> I think it's non-negotiable that if someone has coded a (throw ...)
> or an (error ...), execution cannot continue normally past that
> throw or error
Yes, that'd create havoc, I only meant continue after the `catch' /
`lazy-catch' form.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
