Matthew Flatt <xxxxxx@cs.utah.edu> 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
xxxxxx@pacbell.net  xxxxxx@bothner.com   http://www.bothner.com/~per/