Exceptions ou des codes d'erreur

Question

Nous construisons un service Web (SOAP, .Net) qui parler à (la plupart du temps) clients natifs (fenêtres, C ++) et nous demandons quelle est la meilleure façon de communiquer des erreurs au client (par exemple SomethingBadHappened comme connexion service non disponible ou quelque chose comme utilisateur introuvable) et n'a pas été en mesure de décider entre jeter exception au client ou à l'aide d'une sorte de modèle de code d'erreur de faire ci-dessus.

Qu'est-ce que vous préférez sur la manipulation du côté client: réception d'un code d'erreur ou la manipulation d'une exception ServerFault qui contient la raison de l'erreur
1) Pourquoi nous pensons exception: Parce qu'il ferait code côté serveur beaucoup plus uniforme
2) Pourquoi pensons-nous des codes d'erreur: Parce que nous penser il est plus logique du point de vue du côté client.

Si 2) est vraiment vrai que nous voudrions probablement aller pour les codes d'erreur que des exceptions? Est-ce le cas ici?

En outre, le changement serait de réponse si on parlait aux clients gérés au lieu des clients natifs?

Answer 1

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

En ce qui concerne les meilleures pratiques SOA à définir un défaut générique et quelques défauts spécifiques que si le besoin client afin de gérer différemment un certain type d'erreur. Ne jamais envoyer une trace de la pile d'exception au client dans le déploiement de la production. En effet, en théorie, la trace du serveur n'a pas de signification pour le client et pour des raisons de sécurité aussi bien. Connectez-vous l'erreur complète et stacktrace sur le serveur et envoyer une référence unique au journal de la faute. Dans WCF J'utilise l'exception de Microsoft bloc de manipulation Enterprise Library pour générer un guid et également convertir une exception à la faute SOAP.

Vérifier les conseils Microsoft Pratiques et modèles .

Answer 2

J'ai fait récemment un service Web avec les Java 6 bibliothèques, qui peuvent signaler un retour d'exception à l'appelant (je ne l'ai pas examiné comment comme cela se fait automatiquement).

La possibilité d'avoir le client de fournir une trace de la pile dans le rapport d'erreur au développeur a été très utile (par opposition à obtenir un horodatage approximative et d'avoir à chercher dans vos journaux, si vous arrivez à l'enregistrer).

Alors, vu d'un point de vue des développeurs, des exceptions d'utilisation.

Answer 3

Si c'est un service Web, vous ne pouvez pas faire exactement le serveur de lancer une exception qui sera prise par le client. A l'interface, votre serveur a essentiellement pour retourner 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, vous pourriez avoir votre code de lecture de réponse de vérification de la réponse pour voir si elle contient une erreur et soulever une exception sur le 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, ne pas avoir une bonne remise d'exception, et il est une bonne idée de rester aussi loin de C ++ d'exceptions possible. Si vous ne pouvez pas utiliser une meilleure langue, il suffit de coller à des codes d'erreur.