]> 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