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/