Re: Backtrace and enhanced catch

[Kevin Ryde]

Neil Jerram <address@hidden> 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.