[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> 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.
bothner@xxxxxxxxxxx per@xxxxxxxxxxx http://www.bothner.com/~per/