> Anyway, I think it is not beneficial that an exception handler can return
> to the point of throwing the exception.
>
> Assume that `open-input-file' raises an exception if a file is not found
> and let:
>
> (with-exception-handler
>   (lambda (exception) (display "Funny thing happened") (newline))
>   (lambda ()
>     (let ((port (open-input-file "foo")))
>       (read port))))
>
> Executing this obviously causes `port' to be bound to an undefined value,
> after which `read' will trigger an error that will typically be not an
> exception but a full-blown crash (sort of).  I think that the common
> intuition w/ exception handlers is that they do not return in the standard
> way.  Now, as shown in the document, the exception handler can invoke an
> explicitly captured escape continuation.  However, if
> with-exception-handler would capture the continuation internally, its
> implementation could be possibly optimized.  Moreover, this would inhibit
> the problem above appearing.
>
> Whatever exception systems will ever pop out, I would like to use such one
> that would define with-exception-handler as:
>
> (with-exception-handler handler thunk)                ;procedure
>
>   Returns the result(s) of (thunk), unless an exception is (raise)d, in
>   which case the continuation waiting for the value of (raise) is
>   discarced, (handler exception) is called, and the value(s) of this call
>   is (are) returned.  The number of values returned by (thunk) and
>   by (handler exception) for any exception must match the number of
>   values the continuation of the call to (with-exception-handler) expects
>   to receive.

You have to know what you are doing when you use
"with-exception-handler", so in a sense it is a low-level mechanism
for intercepting exceptions.  I agree that a more foolproof mechanism
would be useful for general use.  However, if there is only one
mechanism to intercept exceptions and it performs an implicit call/cc,
the mechanism will have a high cost on some systems, and it would be
unfortunate to force this high cost when a call/cc is not required.
There are also cases where you want the ability to restart the
computation that raised an exception.  For example, if the heap
overflows the exception handler may be able to free some useless
objects from a table and continue the allocation that caused a heap
overflow.  Similarly, you might want to write a debugger that will
suspend the computation when (load "foo") does not find the file
"foo", allowing the user to create that file and retry the "load".
Check SRFI-21 for some more examples.

Marc