[Mono-list] exceptions are not thrown from ThreadPool'ed thread objects?

Mike Welham mike@digitalnova.co.za
Wed, 20 Oct 2004 10:17:44 +0200

> however it throws if you replace ThreadPool with regular Thread 
> object? is that expected? it would be fine if this was consistent.
> by saying its the right behavior, are you referencing to a CLI document?

I can't find much in the CLI spec. The CLI doc for System.Threading.Thread


If an unhandled exception is thrown in the code executed by a thread created
by an application, a System.AppDomain.UnhandledException event is raised
(System.UnhandledExceptionEventArgs.IsTerminating is set to false), and the
thread is terminated; the current process is not terminated.


There is also an MSDN doc at
http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx that
describes Microsoft's implementation. From that article:


In certain cases, exceptions that are unhandled are swallowed whole by the
CLR (although this behavior is changing in the .NET Framework 2.0). Here is
a summary of the unhandled exception handler default behaviors that are
executing in this application.

    * Unhandled exceptions that occur on the application's main thread cause
the application to terminate.
    * Unhandled exceptions that occur in threads other than the
application's main thread are swallowed by the CLR. This includes manual
threads, thread pool threads, and the CLR's finalizer thread. If your
application is a console application, the CLR outputs exception text to the
console (though your application keeps running). If your application is not
a console application, there is no outward indication when an exception
occurs and your application keeps running.
    * Unhandled exceptions that occur on a thread that is pumping window
messages via the Windows Forms classes are subject to the Windows Forms
unhandled exception handler. A debug dialog box is produced by default, but
this behavior can be overridden (more on this in a moment)."