On Fri, 20 May 2011 05:12:34 -0400, Andy Wingo <wingo@pobox.com> wrote:

> Here is an implementation of `guard' which does evaluate the predicates
> in the raise handler, the bodies with the continuation of the `guard',
> and re-raises from within `raise', but without rewinding.

If you do not re-establish the continuation of the raise, then you affect
the intended behavior of the enclosing exception handlers. Consider the
following:

Chez Scheme Version 8.3
Copyright (c) 1985-2011 Cadence Research Systems

> (define (print-state) (printf "State.\n"))
> (define debug? (make-parameter #f))
> (with-exception-handler
     (lambda (c)
       (when (debug?) (print-state))
       (display-condition c)
       (reset))
     (lambda ()
       (guard
         (c
           [(warning? c)
            (when (debug?) (display-condition c))])
         (parameterize ([debug? #t])
           (raise (make-error))))))
State.
Exception occurred with condition components:
   0. &error
>

This is just an example, but imagine a more complicated exception handler,
such as one that captures its continuation and so forth. I've written such
things, such as a handler that encloses a number of other things that, if
it receives a recoverable error, such as a network failure that can be
re-established, will pass back a new value. If there was a guard inside of
these (and there often is), then the continuation would not be what I
expect, and the value would be passed somewhere else, which breaks my
program. In other words, just inserting a guard somewhere in a program
should not alter the behavior of the program when the guard can't handle
an object.

	Aaron W. Hsu

--
Programming is just another word for the lost art of thinking.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports