Re: [Caml-list] Has the thread cancellation problem evolved ?

[Gordon Henriksen <gordonhenriksen@mac.com>]

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