Exceptions ou codes d'erreur

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?

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 .

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.

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.