Re: [Caml-list] GC and file descriptors

[Benjamin Geer <ben@socialtools.net>]

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