>>usage >>The fundamental question is what is the correct thing to do? The CLR >>answered this by saying that an unhandled exception on the main thread >>terminates the app, otherwise it doesn't. IMO by default it should have >>terminated it for all threads. > >Consider the scenario of a service ala IIS where you spin up threads to >service multiple requests in potentially different AppDomains. You >probably would not want one bad hosted web app to bring down the whole >process. > >-- >Keith >
Good points. In the case where a service spins the threads up all it needs to do is wrap the ThreadStart method body in a try-catch, in essence creating its own backstop handler. It's more problematic when a service creates other appdomains, or loads third party DLLs that create their own threads. In this case I believe the correct design would be a combination of the following: Unhandled exceptions within an appdomain should terminate that appdomain, not necessarily the entire host process. The unhandled exception handler should have the ability, subject to security restrictions, of deciding if the appdomain should be shutdown or if the exception is to be swallowed. This could take the form of a read- write property in the UnhandledExceptionEventArgs, called IsTerminating. Also, the CLR should correct the current deficiency where you can only hook the appdomain's unhandled exception handler from the default appdomain. At the very least, hooking this from an appdomain other then the default should throw an exception (to remind you that it doesn't work), and best case would be to forward the notification to the appdomain where the unhandled exception occurred (this ought to be relatively easy for them to do). Dave =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
