]> Martin Berger wrote: > my (limited) experience with java suggests that in large projects one of > the following happens: > > * all exceptions specs are written out in detail (ie no grouping using > subtyping etc). in this case, way too much code is nothing but exception > specs. > > * the subtyping approach is used. in this case exception specifications > are too imprecise; > > * something that seems like what you refer to as nested exceptions where > you catch exceptions at every layer and convert them into some other > exception. in this case you litter the code with catch statements > that seem superflouos. The second and third approaches can indeed be taken to an extreme in order to render exceptions completely meaningless. However, I think there are reasonable alternatives. In general, I think the design of exception types should be guided by the need to handle different errors differently. When certain errors occur, a program can usefully try to recover, perhaps by waiting a little while and trying again. Other kinds of errors need to be handled by giving up and letting a person sort it out. Depending on what went wrong, that person might be an ordinary user or a system administrator, and the sort of information they'll want to be given will vary accordingly. Exceptions propagate upwards from low-level subsystems into higher-level ones; at some point, the program must take some action in response to the exception. Often this is most reasonably done at the point where a 'unit of work' (something that would be meaningful to the user) was initiated. At that point, the program doesn't care what the precise reason for the exception was; it only needs to know which sort of action to take. Retry? Pop up a dialog box to tell the user that the input was bad and needs to be corrected? Log the error as a bug with a full stack trace, and send an email to the system administrator? With some programs, the user will want to be able to configure which errors are handled in which ways. This suggests that each type of problem that needs (or may need) distinct error-handling behaviour also needs its own exception type. For some programs, it is enough to define three general exception types: (1) error caused by bad user input, (2) error caused by the failure of some external resource, such as a network or a database, and (3) error caused by a bug in the program (assertion failure). (A subtype of (2), indicating that it may be worth retrying, can be useful.) When a more specific exception (such as an I/O error) is caught by a low-level subsystem, it can be wrapped in an exception of one of these three general types, and allowed to propagate upwards until it reaches the function that initiated the unit of work. That function can pass the exception to a subsystem that knows about the user's error-handling configuration, in order to determine whether to retry or just report the error. The error-handling subsystem can also take care of reporting the error in the appropriate way, according to its type. Since the original low-level exception is still there, wrapped in the more general exception, reporting can be as detailed as needed. For other programs, these simple categories will be insufficient, but you get the idea. Ben ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners