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
Has the thread cancellation problem evolved ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-08-28 (09:26)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: [Caml-list] Has the thread cancellation problem evolved ?

Le 28 août 07 à 01:33, Gerd Stolpmann a écrit :

> Nevertheless, I don't think this is a good thing. Raising an exception
> at potentially any moment is a problematic thing. E.g. code like
> let x = try Some(List.assoc ... with _) -> None
> where the author implicitly assumes that it is only Not_found that can
> happen and the code is just plain wrong if anything else is encoded  
> into
> the exception.

But this is sloppy programming anyway. The author is plain wrong in  
assuming that only Not_found can be raised, he is asking for a  
potential time consuming debugging session.

1) If x is polymorphic then List.assoc may raise Invalid_argument  
(because of compare).

2) If the computation of x is embedded in a larger computation the  
call to List.assoc may raise Stack_overflow.

3) The allocation of the block for Some may raise Out_of_memory.

4) If we are in the toplevel Sys.Break may be raised.

IMHO the only place where a catch all handler is allowed is in a  
toplevel main loop (or a function monitoring other computations).