Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] GC and file descriptors
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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


    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.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: