Browse thread
Has the thread cancellation problem evolved ?
[
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: | 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). Daniel