William D Clinger scripsit:
> 1. For buffered i/o and bulk transcoding, it makes
> sense to allow the exception to be raised when the
> invalid encoding is encountered or generated, which
> can come before (input) or after (output) the get-char
> or put-char operation that a naive programmer might
> think of as the cause of the exception.
This kind of asynchrony doesn't work with the R6RS exception-handling
model. In particular, the handler that expects to handle the
encoding error may have been disestablished before the exception
is raised.
> 2. The exception handler for &i/o-decoding might
> be given the invalid encoding as a bytevector that
> is packaged up within the &i/o-decoding condition.
I'm neither for nor against this.
> 3. The port might already have been updated to
> point past the error when the exception handler
> gains control.
That's fine. However, it would be necessary to set a definite
terminus for delaying the exception (say, the closure of the port).
> 4. The exception might be made non-continuable.
> This would greatly reduce the usefulness of the
> raise error handling mode, however, so the raise
> mode should no longer be the default if it is made
> non-continuable.
I'm against continuable exceptions in principle, so obviously I support
this. I agree that the raise mode being the default makes no sense.
--
I now introduce Professor Smullyan, John Cowan
who will prove to you that either cowan at ccil.org
he doesn't exist or you don't exist, http://www.ccil.org/~cowan
but you won't know which. --Melvin Fitting
Received on Mon Jun 18 2007 - 22:39:13 UTC