English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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).