2008-11-05 5 views
0

J'ai lu plusieurs documentations sur la construction de ErrorHandler personnalisé (en héritant de IErrorHandler). Malheureusement, j'ai plusieurs doutes sur la façon de le faire.WCF ErrorHandler

Le problème est que je ne comprends pas exactement le sens des deux méthodes de IErorrHandler (à savoir ProvideFault et HandleError). Pour moi, HandleError est utilisé pour traiter la logique asynchrone (par exemple, la connexion). Mais, dans ce cas, pourquoi cette méthode renvoie-t-elle un booléen? Je pense aussi que l'autre méthode peut être utilisée pour déterminer si une erreur doit être propagée au client ou à quelque chose d'autre.

Je me trompe?

Répondre

2

Basé sur le MSDN documentation, le booléen est de retourner un succès ou l'échec de l'exécution du comportement nécessaire.

Vous avez raison en ce que la méthode est ProviderFault où vous contrôlez ce qui est retourné au client.

Je vous recommande fortement de lire le document MSDN lié, il fournit de bonnes informations.

5

I a mis en oeuvre un gestionnaire à un moment donné pour faire l'enregistrement des exceptions dans le HandleError() et à effectuer des traductions Exception-à-Fault dans le ProvideFault(). Cela a fonctionné assez bien pour moi pendant un certain temps.

Cependant j'ai depuis cessé d'utiliser le IErrorHandler comme je l'ai constaté qu'il ne serait pas se tiré sur toutes les exceptions. Je crois que c'était une exception System.Security.SecurityException qui ne passait pas par ce code. C'était comme si l'équipe spéciale de la WCF l'avait enfermé et l'a simplement passé directement au client. Cela m'a rendu un peu nerveux quand j'ai commencé à me demander ce que je n'étais pas en train d'attraper dans cette interface soi-disant fourre-tout.

+0

Je suis confronté aux mêmes problèmes (SecurityException non intercepté). Avez-vous déjà trouvé un moyen d'attraper ces exceptions? – MvdD