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 (14:24) |
From: | Gordon Henriksen <gordonhenriksen@m...> |
Subject: | Re: [Caml-list] Has the thread cancellation problem evolved ? |
On Aug 28, 2007, at 05:26, Daniel Bünzli wrote: > 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. Such problems are too common to ignore. .NET defuses them by treating ThreadAbortException specially. “When a call is made to the Abort method to destroy a thread, the common language runtime throws a ThreadAbortException. ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block. When this exception is raised, the runtime executes all the finally blocks before ending the thread. Since the thread can do an unbounded computation in the finally blocks, or call Thread.ResetAbort to cancel the abort, there is no guarantee that the thread will ever end.” http://msdn2.microsoft.com/en-us/library/ system.threading.threadabortexception.aspx — Gordon