> 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