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