Tim,

I suspect you already understand (whether or not you agree is another
matter) what I am about to say, but I will throw it in here to emphasize
a couple of things that might be helpful.

====================================
I think the problem in practical terms is that thinking of a suitable
error and then putting proper handlers all over the place is a bugger
of a job. Not to mention that for proper handling you need to have a
sensible strategy for layering the exceptions so that a 'missing
directory' error from the FileDirectory level gets turned into a
'resource not available' for the application and eventually a nice
dialogue for the user that explains that the track they wanted could
not be played because someone seems to have unmounted the disc it is
supposed to be on. Sure, you could let FileDirectory>fileNamed: raise
"self error: 'directory not there dumbo'" but you won't make any
friends. A proper missing directory exception means some code
handling it might be able to attempt automounting other discs or
redirecting to a network or whatever. A missing resource exception at
the next level allows the application to do something suitable which
hopefully includes fixing the problem so the user never needs to know
there was a problem.
====================================

Deriving FileOrDirectoryNotFound from ResourceNotFound will more or less
give the best of both worlds, right?  No trap means the user sees it as
a "crash".  If the directory is seen simply as a generic "resource",
trap that, if more detail is needed and useful, trap
FileOrDirectoryNotFound.

Apologies for stating the obvious.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029