]> > François Pessaux and Xavier Leroy. Type-based analysis of uncaught > exceptions. ACM Transactions on Programming Languages and Systems, > 22(2):340-377, 2000. > http://pauillac.inria.fr/~xleroy/publi/exceptions-toplas.ps.gz i havn't had time to give that paper the proper read it deserves, but the following caught my eye: "to deal properly with higher-order functions, a very rich language for exception declarations is required, including at least exception polymorphism (variables ranging over sets of exceptions) and unions of exception sets [...]. we believe that such a complex language for declaring escaping exceptions is beyond what programmers are willing to tolerate." i'd be happy to have such a language available. anyway, union of exception sets is already present in java, the only novelty would be to abstract over exception sets. but that isn't really formally very different from normal existential or universal quantification. in addition, i assume the programmer does not have to specify exception sets because they can be inferred (in most cases?). in that, exception sets should not be different from the other typing information. in practise, the programmer would use explicit exception specifications only at module boundaries. one of the key problems with exceptions specifications is of course that a single change somewhere in a program may trigger heaps of other code becoming untypable. i can imagine that a simple compiler switch for turning off exception specification checking during development would take away much of the pain here. 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