unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Kevin Ryde <user42@zip.com.au>
Cc: guile-devel@gnu.org
Subject: Re: Backtrace and enhanced catch
Date: Wed, 01 Feb 2006 07:07:55 +1100	[thread overview]
Message-ID: <87k6cgi2jo.fsf@zip.com.au> (raw)
In-Reply-To: 87k6cl8o5c.fsf@ossau.uklinux.net

Neil Jerram <neil@ossau.uklinux.net> 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


  reply	other threads:[~2006-01-31 20:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-01  0:16 gh_inexact_p error in 1.7.x Bruce Korb
2005-12-01  0:44 ` Kevin Ryde
2005-12-05  4:08   ` No way out Bruce Korb
2005-12-05  4:35     ` Bruce Korb
2005-12-07  1:31       ` Marius Vollmer
2005-12-05 22:20     ` Kevin Ryde
2005-12-06 10:58       ` Han-Wen Nienhuys
2005-12-28 15:59         ` Neil Jerram
2005-12-31 15:09           ` Han-Wen Nienhuys
2005-12-31 15:14             ` Neil Jerram
2006-01-01 19:58               ` Han-Wen Nienhuys
2006-01-02 15:42                 ` Neil Jerram
2006-01-02 18:54                   ` Neil Jerram
2006-01-04 21:13                     ` Backtrace and enhanced catch Neil Jerram
2006-01-14 12:41                       ` Neil Jerram
2006-01-22 13:47                         ` Marius Vollmer
2006-01-23 20:11                           ` Neil Jerram
2006-01-24 21:34                             ` Marius Vollmer
2006-01-16  8:38                       ` Ludovic Courtès
2006-01-18 23:08                         ` Neil Jerram
2006-01-19  9:38                           ` Ludovic Courtès
2006-01-21 11:26                             ` Neil Jerram
2006-01-26 23:29                       ` Kevin Ryde
2006-01-27 19:30                         ` Neil Jerram
2006-01-31 20:07                           ` Kevin Ryde [this message]
2006-02-01 23:04                             ` Neil Jerram
2006-02-04  0:46                               ` Kevin Ryde
2006-02-04 15:41                                 ` Neil Jerram
2005-12-07  1:07     ` No way out Marius Vollmer
2005-12-07  1:55       ` Rob Browning
2005-12-13 20:32         ` Marius Vollmer
2005-12-28 16:09       ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k6cgi2jo.fsf@zip.com.au \
    --to=user42@zip.com.au \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).