Re: [Caml-list] GC and file descriptors

[Benjamin Geer <ben@socialtools.net>]

Martin Berger wrote:
>> What alternatives are there?
>> One is to  have exception specifications on functions,
>> but that is known not to work very well. [...]
> 
> but isn't this snowballing exactly what you want?

I think it is.  It's very reassuring to know that the compiler can tell 
me whether I've left any exceptions unhandled, just as it can tell me 
whether I've neglected to provide a suitable return value for a function.

 From experience working on fairly large programs in Java, I can say (at 
the risk of being pelted with stones on this list) that I think the way 
Java handles this works pretty well.  You can avoid having any methods 
specify more than two or three exceptions by using hierarchies of 
exception subtypes (e.g. IOException has subtypes FileNotFoundException, 
SocketException and so on) and by using nested exception objects (e.g. a 
FooSubsystemException can contain an instance of any other exception, 
and can thus be handled by a method that only specifies 
FooSubsystemException).  Nested exceptions have the useful property that 
when you get a stack trace from an exception (e.g. in order to log it), 
it recursively includes the stack traces of any nested exceptions.

In Caml, as in C++, I'm left with a lingering anxiety about what 
exceptions might be thrown (particularly by libraries, including the 
standard libraries) but not handled except by a catch-all 'unhandled 
exception handler', at which point it's too late to do anything useful 
with them.  (And Caml exceptions lack stack traces.)

Annoying problems arise in Java with unchecked exceptions; things like 
IndexOutOfBoundsException (which can be thrown by any array access) or 
ArithmeticException (e.g. division by zero) don't have to be declared in 
exception specifications, and therefore never are.  Bugs often result in 
programs crashing with an unhandled NullPointerException (which of 
course can't happen in Caml).  Ideally, the number of possible unchecked 
exceptions should be kept to an absolute minimum; I think there are too 
many in Java.

I wish I knew what the ideal solution was, but I think Caml could do 
worse than to implement a Java-like approach.  It seems to me that this 
would be more consistent with Caml's overall focus on type safety than 
its current C++-like approach.

 > i always wonder if problem would simply disappear with more
 > expressive typing systems that allow concise specification
 > of the normal case for exceptions -- where an piece of code is
 > just a conduit for exceptions -- and appropriate grouping of
 > exceptions, for example by subtyping.

If the type of a function included its exception specification, could 
Caml infer exception specifications?  If so, perhaps exception 
specifications could be added to the language without breaking backwards 
compatibility.  If I wrote this:

let divide x y = x / y ;;
let do_work x y = divide x y ;;

the type of both functions would be inferred as having an exception 
specification containing Division_by_zero.  Now suppose I wrote the 
following (meaning that the function do_work explicitly specifies the 
exception Sys_error):

let do_work x [ Sys_error ] = let z = (* ... *) in divide x z ;;

I would get a compile error, because I should have written:

let do_work x [ Sys_error; Division_by_zero ] = let z = (* ... *) in 
divide x z ;;

When using libraries that were written before the introduction of 
exception specifications, I could verify that all library exceptions 
were handled, by calling a library function in the following way:

let do_work x [] = (* Call some library functions that don't have 
explicit exception specifications *) ;;

The compiler would then tell me which exceptions I'd failed to handle.

Does this seem feasible?

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