>  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). 

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.

in summary, i do not recommend the java approach (for other reasons too,
like unchecked exceptions).

i think exception specification polymorphism is cruical. maybe some
other ideas are also needed.

martin

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