[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: conditions

This page is part of the web mail archives of SRFI 12 from before July 7th, 2015. The new archives for SRFI 12 contain all messages, not just those from before July 7th, 2015.

Matthew Flatt <mflatt@xxxxxxxxxxx> writes:

> Quoting Per Bothner:
> > * What is the purpose of composite conditions?
> It's a simple mechanism to get the flexibility and extensibility we
> want.
> Again, Richard has already explained this, but I'll repeat for
> completeness. The usual example goes something like this:
> * Filesystem errors are supposed to raise the exception BadFile.
> * Network errors are supposed to raise the exception BadConnect.
> * What exception do you raise when something goes wrong in a
>   network-backed filesystem?
> The ideal answer is "both". That's what composite conditions are for.

I believe that is the wrong answer.  Having a combined object just
mushes things together without a useful result.

The correct answer is that the nework layer throws a BadConnect.
This get caught by the file system layer, which throws a BadFile.
The BadFile exception *wraps* the BadConnect as one of the
properties of the BadFile object.

Most applications will note that a BadFile has happened.
If the BadFile is printed out in "verbose" mode, the
underlying BadConnect will also get printed.

One reason to have a composite exception is so that a user subroutine
that handles BadConnect without handling BadFile will catch the
network-file error.  But that makes no sense:  The user code is
dealing with files; the network is handled by a lower layer.  Thus
there is no way reasonable code can do something reasonable with the
BadConect without handling the BadFile.

In a restart-based model you might have TransientNetworkError,
and allow the user to decide whether to give up or wait longer.
I still can't think of how one could do anything useful with a
composite BadConnect+BadFile object.
	--Per Bothner
bothner@xxxxxxxxxxx  per@xxxxxxxxxxx   http://www.bothner.com/~per/