Si vous pouvez contrôler les threads créés dans l'autre AppDomain, vous pouvez également gérer les exceptions en utilisant tous les blocs-prises dans la principale méthode de fil. À part cela, tant que vous utilisez l'hôte par défaut, je crois que votre hypothèse est correcte. Cependant, si vous hébergez vous-même l'environnement d'exécution, vous pouvez également gérer les exceptions non gérées.
Eh bien, il est possible. Vous devrez créer votre propre hôte CLR. Cela commence avec ICorBindToRuntimeEx(). Vous obtenez pour avoir le contrôle total des AppDomains qui lèvent des exceptions. Et il est d'être utilisé par le logiciel MSFT comme ASP.NET et SQL Server 2005. Lorsque vous écrivez un service , vous travaillez avec la mise en œuvre d'hôte CLR par défaut et termine le processus lorsque l'une exception non gérée est levée, indépendamment de ce que AppDomain a causé l'exception.
Le problème est, hôtes comme ASP.NET et SQL serveur ont un chemin d'exécution code très bien défini . Dans un serveur Web, le code managé s'exécute en raison d'une demande de page . Dans un serveur dbase, il exécute en raison d'une requête. Quand quelque chose se passe mal , ils ont le luxe de tout simplement que la avorter demande a commencé (tuer le AppDomain) et le retour d'un « désolé, ne pouvait pas le faire » état au client . Vous l'avez peut-être vu, écrasant le serveur de forums sur l'ancien site Web était assez trivial mais n'a pas l'arrêter de servir d'autres demandes. Pas vraiment sûr à 100% à ce sujet.
Votre implémentation de service est probablement pas aussi propre. Je ne peux pas dire, vous n'avez rien dit à propos de . En général, il y a un problème avec l'abandon d'un thread. Vous avez toujours devez annuler un thread lorsqu'il existe une exception non gérée . Un service a généralement un thread, démarré par la méthode OnStart(). L'annuler tue le serveur jusqu'à ce que quelqu'un arrête et le redémarre.
Vous pouvez certainement le rendre plus résistant que , vous pouvez démarrer un thread « maître » qui lance threads enfants en réponse à des événements externes qui rend votre service faire son travail. Avoir un thread fils terminé en raison d'une exception non gérée est quelque chose que vous pourriez éventuellement récupérer à partir de. Mais ensuite, si vous faites cette prochaine étape , pourquoi ne pas avoir le thread enfant attraper une exception et le renvoyer à le fil principal de sorte qu'il peut prendre une décision intelligente suivant ce qu'il faut faire suivant.
Le fait froid et dur de l'hôte par défaut CLR est la suivante: si vous n'êtes pas prêt à face à l'échec, il ne va pas faire le travail pour vous. Et il ne devrait pas, le comportement .NET 1.x aux threads que est mort avec des exceptions était une erreur majeure qui a été corrigée dans .NET 2.0.
Vous savez quoi faire: gérer les pannes. Ou écrivez votre propre hôte. Ou accepter que choses pourraient être au-delà de votre contrôle et enregistrer un bon message d'erreur afin que vous pouvez dire à votre client quoi faire. Je recommande fortement ce dernier.