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: | -- (:) |
| 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