Code d'erreur ou exception - quelle est la meilleure pratique pour un service Web ASP.Net?

Question

J'ai lu ce fil pour WCF qui contient des codes de défaillance personnalisés et d'autres éléments.

Mais quelle est la meilleure pratique pour les services Web ASP.Net ? Dois-je lancer des exceptions et laisser le client gérer l’exception ou envoyer un code d’erreur (succès, échec, etc.) sur lequel le client s’appuierait pour effectuer son traitement?

Mise à jour: pour discuter plus en détail de SOAP , supposons que le client passe un appel web svc qui est censé être un message de notification (aucune valeur de retour attendue). ), donc tout se passe bien et aucune exception n'est projetée par la svc.

Maintenant, comment le client saura-t-il si l'appel de notification a été perdu à cause d'un problème de communication / réseau ou de quelque chose entre le serveur et le client? comparez cela avec l'absence d'exception. Le client peut supposer que c'est un succès. Mais ce n'est pas. L’appel a été perdu quelque part.

Est-ce que l'envoi d'un code d'erreur 'succès' garantit au client que l'appel s'est déroulé sans heurts? existe-t-il un autre moyen de réaliser cela ou le scénario ci-dessus est-il même possible?

Answer 1

Jeff Atwood a publié un article intéressant sur ce sujet il y a quelque temps. Bien qu'une exception .NET soit convertie en SoapFault, compatible avec la plupart des autres toolkits, les informations contenues dans les erreurs ne sont pas très bonnes. L'article conclut donc que les services Web .NET ne génèrent pas de très bons messages d'exception et que vous devez ajouter des informations supplémentaires:

Private Sub WebServiceExceptionHandler(ByVal ex As Exception)
    Dim ueh As New AspUnhandledExceptionHandler
    ueh.HandleException(ex)

    '-- Build the detail element of the SOAP fault.
    Dim doc As New System.Xml.XmlDocument
    Dim node As System.Xml.XmlNode = doc.CreateNode(XmlNodeType.Element, _
        SoapException.DetailElementName.Name, _
        SoapException.DetailElementName.Namespace)

    '-- append our error detail string to the SOAP detail element
    Dim details As System.Xml.XmlNode = doc.CreateNode(XmlNodeType.Element, _
        "ExceptionInfo", _
        SoapException.DetailElementName.Namespace)
    details.InnerText = ueh.ExceptionToString(ex)
    node.AppendChild(details)

    '-- re-throw the exception so we can package additional info
    Throw New SoapException("Unhandled Exception: " & ex.Message, _
        SoapException.ClientFaultCode, _
        Context.Request.Url.ToString, node)
End Sub

Plus d'informations sur les raisons pour lesquelles les erreurs soap sont mieux dans cette question .

Answer 2

Cela dépend de la manière dont vous allez utiliser le service Web - c’est-à-dire du protocole que vous allez utiliser.

S'il s'agit de GET ou POST, il est préférable de renvoyer le code d'erreur, car l'appelant HttpWebRequest (.Net) ou un autre code recevra une erreur de serveur et devra être traité pour extraire le code d'exception.

Si c'est SOAP - alors il est parfaitement correct de lancer des exceptions personnalisées (vous ne voulez pas renvoyer d'exceptions de cadre internes, car elles pourraient révéler une trace de pile, etc. à des parties externes).

Etant donné que les services Web SOAP sont conçus de manière à considérer le code appelant comme un appel de méthode normal, le framework appelant correspondant doit être capable de gérer et de propager l'exception parfaitement, ce qui permet au code d'appel de se comporter et de se comporter comme il se doit. avec des appels internes.