2009-07-10 7 views
2

Nos services WCF génèrent occasionnellement un thread de travail pour gérer quelque chose dont le client ne tient pas compte. Les threads de travail ne signalent aucun état au client. En fait, le service a probablement déjà renvoyé des résultats au client au moment où le thread se termine.Gestion des exceptions de thread dans WCF

L'un de ces threads d'arrière-plan a récemment provoqué une exception. L'exception n'est pas gérée, donc IIS s'est écrasé.

Je peux corriger cette exception particulière, mais dans le futur, quelqu'un peut ajouter du code qui provoque une autre exception inattendue. Je veux empêcher cela de planter IIS à l'avenir.

Je sais que les applications System.Windows.Forms peuvent gérer les exceptions de thread en implémentant Application.ThreadException. Y a-t-il quelque chose de similaire que je peux faire avec un service WCF? Ou si Application.ThreadException est la voie à suivre, comment pourrais-je l'accrocher à partir d'un service WCF?

La documentation MSDN pour AppDomain.UnhandledException indique qu'il n'empêche pas le blocage. Docs pour ServiceModel.AsynchronousThreadExceptionHandler suggère que ce n'est que pour les threads WCF. Au minimum, je voudrais récupérer une trace de la pile de l'exception avant de planter, mais éviter les accidents futurs serait tout à fait idéal. Encore une fois, permettez-moi de souligner que ce n'est pas une exception que je veux retourner en tant que faute WCF à un client.

Répondre

1

Puisque vous ne savez pas ce qui a causé l'exception, la seule chose sensée à faire est de planter. Vous n'avez aucune idée de l'état du service et vous pourriez empirer les choses en continuant. N'oubliez pas que IIS redémarrera le service pour vous, nettoiera et fonctionnera vraisemblablement.

+1

S'il vous plaît dire la raison de la downvote. Il est peu probable que les réponses s'améliorent sans savoir ce qui ne va pas chez elles. –

+0

Je suis d'accord avec cela ... si vous avez une exception attendue, vous devriez le gérer à proximité de son origine. Si c'est inattendu, cela devrait permettre à l'application de planter. –

+0

Notre code dans les threads de travail ne fera rien de fou qui aurait laissé des choses dans un état inconnu. À moins que IIS lui-même ne soit bloqué, je préfère ne pas planter. Je préfère enregistrer le problème et continuer à le faire. (Notez que je n'ai rien refusé.) –

1

Si vous générez des threads, vous devez toujours s'assurer qu'ils ont des gardes d'exception. La gestion AppDomain pour les exceptions non gérées fournit uniquement un moyen de consigner et de tracer l'erreur, mais cela n'empêche pas l'hôte de se bloquer.

+0

Ouais, j'espère que tout le monde enchaînera les méthodes de thread avec un essai/catch de haut niveau. Comment connecter le gestionnaire AppDomain.UnhandledException dans un service WCF? –

+0

Vous devez le faire au démarrage du domaine. Cela peut être soit quelque chose dans votre code de démarrage si vous avez un hôte personnalisé, ou dans votre Global.asax si vous hébergez dans IIS, comme dans une application régulière asp.net. – tomasr

Questions connexes