Comment gérer les erreurs d'une méthode de façade qui effectue de nombreuses modifications de fond disparates?

Question

Imaginez que j'ai un service qui ressemble à ceci:

public interface MyAccountService 
{ 
    boolean create(String user); 
} 

La méthode crée effectue plusieurs changements, à savoir (pour l'amour de discussion):

1. ajoute un message dans une file d'attente
2. ajoute une ligne dans plusieurs tables
3. crée un compte LDAP, etc ...

Actuellement, je réduis tous les messages d'erreur en une seule valeur de retour booléenne. Maintenant, en interne s'il y a une erreur, je vais les enregistrer pour l'équipe de support.

par exemple. un journal typique d'une création d'utilisateur a échoué

création de compte "alistair" dans l'ordre suivant (stricte):

• ajouter à la table Foo: succès
• ajouter à la table Bar: succès
• ajouter à LDAP: a échoué
• ajouter à la file d'attente: succès

de cette façon, les gens du support technique peuvent décider comment réparer la Accou NT.

Quelle est la meilleure pratique pour concevoir des systèmes tels que nous pouvons facilement suivre le succès/échec d'une transaction (et le réparer manuellement)? Retourne booléen & Avaler toutes les exceptions un bon design?

EDIT: Par exceptions déglutition, je voulais dire ne pas les jeter le l'appelant. Cependant, je consigner les exceptions et les traduire en une valeur de retour false/true.

Answer 1

Vous avez 2 options sur celui-ci à mon avis: 1. Jetez une exception personnalisée avec la liste des succès, ainsi le Le client de l'API peut intercepter l'exception et voir ce qui a échoué, puis décider de l'action à effectuer. 2. Renvoyer un ENUM dans lequel vous reflétez tous les résultats possibles du résultat, donc encore
le client de l'API peut décider quelle action il va effectuer.

De toute façon, vous devez vous connecter tous les problèmes rencontrés par votre méthode afin qu'il puisse être suivi ... Exception et problème d'avaler est une très mauvaise pratique.

J'aime plus la méthode personnalisée d'exception, pour l'ENUM est plus C comme API ..

Answer 2

Cela dépend du besoin.

Si l'exception est due aux informations incorrectes envoyées par le client et que vous voulez qu'elles sachent qu'elles les corrigent, vous devriez alors lancer l'exception.

Si l'exception est due à un problème interne, mais que vous souhaitez toujours que le client sache, lancez l'exception.

Answer 3

Non, ce n'est pas le cas. Toutes les informations disponibles sur l'exception doivent être consignées. (y compris mais sans s'y limiter: Type d'exception, Message, Stack Trace, ...)

Answer 4

J'aime l'approche décrite dans l'article presented here, il y a une discussion à ce sujet here ...

l'idée est de considérer comme genre d'exceptions et de les traiter différemment:

un type d'exception est une éventualité, ce qui signifie qui a été exécuté un processus qui ne peut pas réussir en raison d'un problème connu (l'exemple qu'il utilise est-ce d'ac hecking account, lorsque le compte ne dispose pas de fonds suffisants, ou qu'un chèque fait l'objet d'un arrêt de paiement.) Ces problèmes doivent être traités au moyen d'un mécanisme distinct, et le code doit s'attendre à les gérer.

L'autre type d'exception est un défaut , comme le IOException. Un défaut n'est généralement pas quelque chose que est ou devrait être prévu, et donc la gestion des défauts devrait probablement faire partie d'un processus normal.