Exceptions dans les services Web

Question

Mon groupe développe une application basée sur les services (.NET WCF) et nous essayons de décider comment gérer les exceptions dans nos services internes.Devons-nous lever des exceptions ?Renvoyer les exceptions sérialisées au format XML ?Renvoyez simplement un code d'erreur ?

Gardez à l’esprit que l’utilisateur ne verra jamais ces exceptions, c’est uniquement pour d’autres parties de l’application.

Answer 1

Utilisations de WCF SoapFaults comme moyen natif de transmettre les exceptions soit du service au client, soit du client au service.

Vous pouvez déclarer une erreur SOAP personnalisée à l'aide de la commande FaultContract attribut dans votre interface de contrat :

Par exemple:

[ServiceContract(Namespace="foobar")]
interface IContract
{
    [OperationContract]
    [FaultContract(typeof(CustomFault))]
    void DoSomething();
}


[DataContract(Namespace="Foobar")]
class CustomFault
{
    [DataMember]
    public string error;

    public CustomFault(string err)
    {
        error = err;
    }
}

class myService : IContract
{
    public void DoSomething()
    {
        throw new FaultException<CustomFault>( new CustomFault("Custom Exception!"));
    }
}

Answer 2

Eh bien, pourquoi ne pas simplement lancer les SOAPExceptions standard ?Le problème avec les codes d'erreur et le XML sérialisé est qu'ils nécessitent tous deux une logique supplémentaire pour reconnaître qu'une erreur s'est réellement produite.Une telle approche n'est utile que si vous disposez d'une journalisation ou d'une logique spécialisée qui doit avoir lieu de l'autre côté du service Web.Un tel exemple serait de renvoyer un indicateur indiquant "vous pouvez continuer" avec un rapport d'exception d'erreur.

Quelle que soit la manière dont vous le lancez, cela ne rendra pas le travail plus facile, car le côté appelant doit toujours reconnaître qu'il y a eu une exception et la gérer.

Answer 3

Je suis un peu confus, je ne suis pas désinvolte - vous dites que vous souhaitez renvoyer les exceptions sérialisées au format XML d'une part et que l'utilisateur ne verra jamais les exceptions d'autre part.Qui verra ces exceptions ?

Normalement, je dirais d'utiliser des contrats de faute WCF.

Answer 4

Phil, différentes parties de l'application s'appellent en utilisant WCF.Par « retourner des exceptions sérialisées au format XML », je voulais dire que la valeur de retour de la fonction serait un objet d'exception.Le succès serait indiqué par null.

Je ne pense pas que ce soit la bonne option.

Les contrats de faute WCF semblent bons, mais je n'en sais rien.Je vérifie Google en ce moment.

Answer 5

J'éviterais de renvoyer les exceptions directement au client, à moins que vous ne soyez d'accord avec le renvoi d'autant de détails.

Je recommanderais d'utiliser les erreurs WCF pour transmettre votre message d'erreur et votre code (quelque chose qui peut être utilisé pour décider du destinataire de réessayer, d'erreur, etc.) selon que c'est l'expéditeur ou le destinataire en faute.

Cela peut être fait en utilisant FaultCode.CreateReceiverFaultCode et FaultCode.CreateSenderFaultCode.

Je suis en train de vivre cela en ce moment, mais je me suis heurté à un problème désagréable, semble-t-il, dans la réponse SOAP 1.1 générée par la faute WCF.Si vous êtes intéressé, vous pouvez consulter ma question à ce sujet ici :

Erreurs .NET WCF générant des valeurs de code d'erreur SOAP 1.1 incorrectes