]> > >>>This is the problem with checked exceptions in Java: the set of > >>>exceptions that can be thrown is an implementation detail which is > >>>exposed unnecessarily through the API. > >> > >>IMO it is part of the interface, just like the return type of the > >>functions. > > > > I think in academia you can say these things. But on the sprawling > > real projects, badly managed, written by poorly skilled programmers, > > checked exceptions are a really bad idea. (Trust me on this one, I've > > worked on several such projects). > > I design moderately large Java projects for a living, and I think > checked exceptions are the only thing that forces poorly skilled and > indifferent programmers to do any error handling at all. When a > designer establishes a sensible policy regarding exceptions, checked > exceptions make it possible to be reasonably confident that (nearly) all > error conditions are handled in a sane manner. On a large project, this > is a precious advantage. > > There's nothing worse than using a library without having any idea what > exceptions it might throw. It's like playing Russian roulette. It can work in an opposite way. I've seen developpers (professional) that couldn't break the specification by adding an throws statement so they were simply catching .... and ignoring the exceptions ! There's nothing worse than using a library without having any idea what error happened inside it . It's like playing Seattle roulette :-) Nicolas Cannasse ------------------- 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