Les services Web doivent-ils générer des exceptions OU des objets de résultat?

Question

Je ne suis pas sûr de vraiment être heureux de pouvoir lancer des exceptions dans les services Web. Cela ne me dérangerait pas autant s'il n'y avait pas la trace de pile. Ce n'est pas quelque chose que je ne veux pas.

J'ai effectué des recherches sur plusieurs implémentations et il ne semble pas vraiment y avoir de consensus à ce sujet. CampaignMonitor, par exemple, renvoie un objet Result, mais pas d'autres.

D'un point de vue architectural, je ne suis pas sûr que renvoyer un objet de retour ait du sens. Une exception est certes une exception, mais ce que j'aime bien avec un objet de retour, c'est qu'il s'agit d'une solution plus élégante pour l'utilisateur final.

Quelqu'un a-t-il de meilleures solutions?

EDIT

BTW J'utilise les services Web ASMX, pour lesquels activer CustomErrors n'est pas une option.

Answer 1

De quelle trace de pile parlez-vous? Avez-vous essayé cela?

Dans les services ASMX et WCF, une exception non interceptée sera traduite en une erreur SOAP. Dans les deux cas, ils peuvent être configurés pour ne pas inclure de trace de pile. En fait, c'est la valeur par défaut dans WCF.

Donc, la bonne façon de renvoyer une erreur comme celle-ci est par le biais d’une faute. Une façon de générer des erreurs est de lancer et de ne pas gérer une exception.

Answer 2

Ne laissez pas le fait que vous soyez dans un service Web confondre le problème. Ce n'est qu'un détail de la mise en œuvre.

Utilisez votre stratégie de gestion des exceptions normale. La meilleure pratique consiste à ne pas intercepter les exceptions dans du code de bas niveau - à moins que vous ne puissiez résoudre cette exception et continuer normalement. Les exceptions doivent être générées au niveau de la présentation afin que l'utilisateur puisse être informé de l'erreur.

Ainsi, tel qu’il est appliqué aux services Web - en général, lève des exceptions (ce qui entraîne un défaut SoapFault). Cela permet au code client appelant d’utiliser son standard intégré de gestion des exceptions pour le gérer.

Answer 3

Une approche consiste à séparer les erreurs système et les erreurs commerciales. (Erreur système: demande malformée, utilisateur non autorisé, etc.; erreur commerciale: par exemple, la méthode UpdateCars génère une erreur, l'utilisateur ne possède pas de voiture.)

.

En cas d'erreur commerciale, renvoyez un objet de réponse contenant une description de l'erreur. en cas d'erreur système, déclenche une exception.

Answer 4

Pouvez-vous clarifier un peu? Le côté serveur d'un service Web peut générer une exception. Le côté serveur d'un service Web peut renvoyer un message au côté client. Ce message peut contenir des informations d'erreur et ces informations d'erreur peuvent inclure spécifiquement les détails de l'exception. Ou peut-être pas. Côté client, vous avez généralement un proxy généré pour traiter le message du serveur. Ce proxy peut générer une exception si cette réponse contient des informations d'erreur.

Sur quelle partie de ce scénario vous interrogez-vous?

Answer 5

Je suppose que le fait de lancer des exceptions est en général un meilleur modèle de conception que de renvoyer un résultat. Je suppose que vous devez masquer la trace de la pile dans vos services Web en appliquant le modèle suivant à chaque méthode exposée en tant que service Web:

  

public void MyWebServiceMethod ()   {
    essayer
    {

 ///Do something that may cause an error

     

} catch (Exception ex)
     {         lancer une nouvelle ApplicationException (" User friendly   description de l'exception ");

     

}

     

}

ou vous pouvez aussi

  

catch (Exception ex) {       lancer ex; }

Si vous relancez une exception, vous masquerez la trace de pile d'origine des clients de vos services Web.

Answer 6

Je ne vois pas pourquoi tu ne peux pas faire les deux? Attrapez l'exception, enregistrez-la (dans une base de données ou dans un fichier), puis renvoyez un code d'erreur. De cette façon, vous avez une exécution en douceur de l’appel du service Web, une notification de l’erreur et un autre endroit où vous pouvez procéder au débogage.