Browse thread
[Caml-list] GC and file descriptors
-
Dustin Sallings
- David Fox
- Nicolas George
- Mikael Brockman
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2003-11-19 (18:03) |
From: | Martin Berger <martinb@d...> |
Subject: | Re: [Caml-list] GC and file descriptors |
Richard Jones wrote: >> forall A B E: (A -> B throws E) -> list[A] -> list[B] throws E. > Yes, all well and good, but I *do not* want have to go and change all > .mli files to support checked exceptions, and then go and change them > all again when I decide to put a SQL database behind some persistence > library deep in the code. for a start, the universal quantification above (for a map function) deals with this just fine. it can handle whatevery you throw. i do think however, that there is a problem with declaring the exceptions a function can throw. i think what the type should really declare is something like the exceptions the synax of the function body *adds*. eg a function let f n = let g = send_to_network n in let h = write_do_DB g in if n > 17 then throw Micky_Mouse else 666 should be typable as f : nat -> nat adds Micky_Mouse and not *just* as f : nat -> nat throws E, Micky_Mouse where E is whatever send_to_network and write_to_DB throw. one compromise may be to add an explicit exception spec grabbing operator so we can write f : nat -> nat throws ex(send_to_network), ex(write_to_DB), Micky_Mouse or f : nat -> nat adds ex(send_to_network), ex(write_to_DB), Micky_Mouse where in the latter case ex( f ) gives all the exceptions f adds while in the former case it returns all exceptions f throws. note that at link time, when we put all modules together, the accumulated "adds" information determines the usual "throws" information. of course "adds" and "throws" can live harmoniously together. > 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. again, i don't think this is an implementation detail. if you are a library vendor, i as a customer want to know if your library throws SQL exceptions or not. 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