> > 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 states: <quote> 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. </quote> 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: <quote> 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)." </quote> Regards Mike _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
