Où exceptions de capture

Question

J'ai un svc WCF séparé en une couche de service, couche logique métier et la couche d'accès aux données.

Quand mon DAL rencontre une exception, dois-je l'attraper là-bas ou le laisser revenir à bulles jusqu'à la couche de service? Et pourquoi?

S'il vous plaît ne pas tenir compte toute implication du client pour ce scénario, je ne suis concerné par l'exploitation forestière des exceptions au svc WCF.

Answer 1

Il dépend aussi de la façon dont vous architecturer votre solution. Par exemple, si les DAL et les couches BLL sont censées être des composants totalement indépendants, ils ne peuvent pas faire des suppositions sur qui les appelle. A ce titre, ils devraient les exceptions prises sur la frontière composante, connectez-vous ces exceptions, puis permettre à l'exception de se propager. Ils peuvent vouloir envelopper l'exception générale à une exception spécifique à la couche:

catch (Exception ex)
{
    Logger.Log(ex);
    throw new DalException("Unhandled exception in DAL", ex);
}

Si vous connaissez ceux-ci ne seront utilisés dans le cadre de votre demande globale, vous pouvez reporter l'enregistrement à la couche la plus externe - la couche qui, si elle ne saisit pas l'exception, l'exception ne sera pas connecté.

Answer 2

Il y a un terme pour cela - Exception Shielding. Fondamentalement, vous devez éviter les exceptions système pour Voyage à un niveau supérieur, car cela pourrait donner une atacker vue de l'architecture de votre système. WCF Exception peut Shielding intercepter les exceptions de certains types et les remplacer par des exceptions d'un autre type. Par exemple, il pourrait attraper exception StackOverflow et le remplacer par votre SystemException personnalisé. Si vous utilisez Enterprise Library, vous pouvez aussi configurer pour connecter ces exceptions quand ils sont remplacés

Utilisation de la gestion des exceptions Block dans Enterprise Library 3.0

Answer 3

Je suppose que cela dépend de la façon dont le service est consommé et qui (si quelqu'un) que vous voulez informé lorsqu'une exception se produit.

Par exemple, si vous développez une application métier interne critiques, vous voudrez peut-être les détails de l'exception à bulles à travers la couche de service à l'interface utilisateur qui consume l'application de sorte qu'ils finissent par l'utilisateur peuvent contacter un développeur pour obtenir rapidement le problème résolu.

Cependant, supposons que votre service est consommé par une page Web publique. Vous voulez sans doute encore la couche de service pour attraper l'erreur d'une certaine façon, mais vous pouvez choisir de passer un minimum d'informations au client final, fournir un message d'erreur générique à l'utilisateur final, et d'écrire les détails de l'exception à un journal d'erreurs les développeurs à examiner.

En fin de compte, je pense toujours que vous voulez que l'exception à bulles jusqu'à la couche de service, mais la façon dont vous gérez l'exception et de décider quelles sont les informations à transmettre au client final est à vous.

Answer 4

J'utilise habituellement un gestionnaire d'erreur générique (mise en œuvre de System.ServiceModel.Dispatcher.IErrorHandler) qui est attaché aux services Web par un ServiceBehavior dans le fichier de configuration.

La méthode de IErrorHandler.ProvideFault intercepte les exceptions lancées par le service et:

• Journaux les;

• Laissez-passer à travers FaultExceptions tel quel;

• "affaires" Convertit exceptions (par exemple, des violations de règles métier) lancées par le BLL à FaultExceptions avec un code de défaut "expéditeur / client";

• Convertit exceptions techniques (par exemple, lancés par le DAL) à FaultExceptions avec un code d'erreur "récepteur / serveur".

De cette façon, le code de service lui-même ne contient que le code de l'entreprise et n'a pas besoin de prendre des exceptions.