Exceptions ou codes d'erreur

12

Nous construisons un service Web (SOAP, .Net) qui s'adresserait (principalement) à des clients natifs (Windows, C ++) et nous nous demandons quelle est la meilleure façon de communiquer des erreurs au client (par exemple SomethingBadHappened comme service de connexion non disponible ou quelque chose comme l'utilisateur introuvable) et n'ont pas été en mesure de décider entre lever l'exception pour le client ou utiliser une sorte de modèle de code d'erreur pour faire ce qui précède.

Qu'est-ce que vous préférez sur la gestion côté client: recevoir un code d'erreur ou gérer une exception ServerFault qui contient la raison de l'erreur?
1) Pourquoi pensons-nous à l'exception: Parce que cela rendrait le code côté serveur beaucoup plus uniforme
2) Pourquoi pensons-nous aux codes d'erreur: Parce que nous pensons que cela a plus de sens du point de vue du client.

Si 2) est vraiment vrai, nous voudrions probablement opter pour des codes d'erreur plutôt que des exceptions? est-ce le cas ici?

De plus, la réponse changerait-elle si nous parlions à des clients gérés au lieu de clients natifs?

Amit Wadhwa
la source
Juste pour ajouter un peu de clarification: a) Je recherche ici les meilleures pratiques et l'expérience du côté client (car le client est beaucoup plus compliqué et nous préférerions gérer les choses côté serveur si nous pouvons garder le code client plus simple) b) Le client contient beaucoup de code hérité et nous pouvons ou non être en mesure d'utiliser des exceptions C ++.
Amit Wadhwa du
Cela peut aider
Gulshan

Réponses:

8

SOAP a un concept de défauts , vous pouvez convertir une exception en défaut côté serveur et sur le proxy client, le défaut peut à nouveau être reconverti en exception. Cela fonctionne remarquablement bien dans la pile de métro WCF et Java, ne peut pas commenter les clients C ++ natifs.

En ce qui concerne les meilleures pratiques SOA, définissez un défaut générique et quelques défauts spécifiques uniquement si le client a besoin de traiter un certain type d'erreur différemment. N'envoyez jamais de trace de pile d'exceptions au client dans le déploiement de production. En effet, en théorie, la trace du serveur n'a aucune signification pour le client et pour des raisons de sécurité également. Enregistrez l'erreur complète et la trace de pile sur le serveur et envoyez une référence unique au journal de l'erreur. Dans WCF, j'utilise le bloc Microsoft Exception Handling de Enterprise Library pour générer un GUID et convertir également une exception en erreur SOAP.

Consultez les instructions de Microsoft Patterns and Practices .

softveda
la source
Merci, ça sonne bien. Pouvez-vous me donner un lien plus spécifique dans la page là-bas.
Amit Wadhwa
Qu'en est-il également des erreurs au niveau de l'entreprise comme UserNotFound, etc. devraient-elles également être traitées comme des exceptions?
Amit Wadhwa
Il est passé des projets que nous n'avons jamais utilisés d'exceptions dans le code ou de défauts dans SOAP pour communiquer les modes de défaillance légitimes / attendus. Nous avons utilisé des codes d'erreur et les avons laissés au client de décider quoi en faire. L'utilisateur non trouvé n'est pas vraiment une erreur / exception, cela devrait probablement être un code d'état.
MrLane
4

J'ai récemment fait un service Web avec les bibliothèques Java 6, qui peuvent signaler une exception à l'appelant (je n'ai pas vérifié comment cela se fait automatiquement).

La possibilité de demander au client de fournir une trace de pile dans le rapport d'erreur au développeur a été très utile (au lieu d'obtenir un horodatage approximatif et de le rechercher dans vos journaux, si vous vous connectez).

Donc, vu du point de vue des développeurs, utilisez les exceptions.


la source
1
Je suis d'accord que cela pourrait être utile dans dogfood et beta, mais voulez-vous vraiment cracher des traces de pile dans les journaux d'événements ou les fichiers journaux en utilisation réelle (et bien sûr révéler plus de détails sur le service que vous n'en avez besoin / que vous voulez en cours de traitement) )
Amit Wadhwa
2
@Amit, croyez-moi: si vous rencontrez une situation donnant une trace de pile en production, vous VOULEZ la trace de pile!
1
Quel est l'avantage sur la trace de pile côté client, nous allons certainement enregistrer toutes les exceptions côté serveur avant de les transmettre au client.
Amit Wadhwa du
Qu'en est-il également des erreurs au niveau de l'entreprise comme UserNotFound, etc. devraient-elles également être traitées comme des exceptions?
Amit Wadhwa
-2

S'il s'agit d'un service Web, vous ne pouvez pas provoquer exactement le serveur de lever une exception qui sera interceptée par le client. À l'interface, votre serveur doit essentiellement renvoyer une sorte de code d'erreur, même si c'est une chaîne qui dit An exception occurred. Type %s, message %s, stack trace %s.

En ce qui concerne le côté client, votre code de lecture de réponse pourrait vérifier la réponse pour voir si elle contient une erreur et déclencher une exception du côté client. C'est une très bonne façon de le faire, dans les langues avec une bonne gestion des exceptions au moins. C ++, cependant, n'a pas une bonne gestion des exceptions, et c'est une bonne idée de rester aussi loin des exceptions C ++ que possible. Si vous ne pouvez pas utiliser une meilleure langue, respectez simplement les codes d'erreur.

Mason Wheeler
la source
Je suppose que l'exception non interceptée irait en tant que ServerFault au client
Amit Wadhwa
3
Il n'y a rien de mal avec les exceptions C ++ ou C ++. Il existe de nombreuses raisons d'utiliser un langage autre que C ++ pour certains projets, mais la gestion des exceptions n'en fait pas partie.
KeithB
Non seulement cela va à l'encontre des meilleures pratiques de sécurité: que doit faire exactement le client avec la trace de pile de votre serveur? L'imprimer et vous l'envoyer? Envoyer par e-mail? Utiliser pour du papier lubrifiant?
JensG
@JensG: S'il s'agit d'un service Web et non d'un site Web , le client doit être suffisamment professionnel pour vous l'envoyer par e-mail sous forme de rapport de bogue.
Mason Wheeler