问题
I'm having trouble with a misbehaved library that throws an exception in a finalizer, which of course crashes the application.
To avoid this, I tried loading the library in its own AppDomain, but the exception still bubbles to the surface and crashes the application.
As documented on MSDN, registering to AppDomain.UnhandledException doesn't prevent the exception from bubbling up, but I'm quite surprised that there is no other way to catch such an exception in a "sub AppDomain".
How do plugin hosts, or applications that use AppDomains to sandbox potentially harmful code, do to stop unhandled exceptions ? Is it in fact possible ?
Note: I already have another workaround, the one described here. The bad finalizer is on a long-lived object, which seems to be only collected during shutdown, so it is sufficient to hide this "bogus" error from the user. Still, I find this workaround brittle, since it will either hide other, real errors, or risk blowing up my application if the object is collected earlier.
回答1:
An AppDomain is nice since you can ditch the program state but you still have the problem that the thread is dead. That this happens on the finalizer thread is fatal, the CLR will abort the process without recourse.
The only 'fix' is to run this component in its own process. You can shoot it in the head with Process.Kill() to prevent the finalizer thread from running at process exit. Use one of the interprocess communication mechanisms that .NET supports to talk to it. A socket, named pipe, Remoting or WCF. Good luck with it.
回答2:
Actually, back in .NET 1.0/1.1, it behaved as you need. You can still revert to this behavior by simply adding this row to your application configuration file, inside the "runtime" node:
<runtime>
<legacyUnhandledExceptionPolicy enabled="1"/>
</runtime>
This will prevent an unhandled exception in a different thread from terminating the entire process.
来源：https://stackoverflow.com/questions/3906282/can-i-prevent-an-uncaught-exception-in-another-appdomain-from-shutting-down-the