Teilen über

Definieren und Angeben von Fehlern

SOAP-Fehler vermitteln Fehlerbedingungsinformationen von einem Dienst an einen Client und im Duplexfall von einem Client zu einem Dienst auf interoperable Weise. In diesem Thema wird erläutert, wann und wie sie benutzerdefinierte Fehlerinhalte definieren und angeben, welche Vorgänge sie zurückgeben können. Weitere Informationen dazu, wie ein Dienst oder Duplexclient diese Fehler senden kann und wie ein Client oder eine Dienstanwendung diese Fehler behandelt, finden Sie unter Senden und Empfangen von Fehlern. Eine Übersicht über die Fehlerbehandlung in Windows Communication Foundation (WCF)-Anwendungen finden Sie unter Angeben und Behandeln von Fehlern in Verträgen und Diensten.

Überblick

Deklarierte SOAP-Fehler sind diejenigen, in denen ein Vorgang einen System.ServiceModel.FaultContractAttribute benutzerdefinierten SOAP-Fehlertyp angibt. Nicht deklarierte SOAP-Fehler sind solche, die im Vertrag für einen Vorgang nicht angegeben sind. In diesem Thema können Sie diese Fehlerbedingungen identifizieren und einen Fehlervertrag für Ihren Dienst erstellen, den Clients verwenden können, um diese Fehlerbedingungen ordnungsgemäß zu behandeln, wenn sie von benutzerdefinierten SOAP-Fehlern benachrichtigt werden. Die grundlegenden Aufgaben sind in der Reihenfolge:

  1. Definieren Sie die Fehlerbedingungen, die ein Client Ihres Diensts kennen sollte.

  2. Definieren Sie den benutzerdefinierten Inhalt der SOAP-Fehler für diese Fehlerbedingungen.

  3. Markieren Sie Ihre Vorgänge so, dass die spezifischen SOAP-Fehler, die sie auslösen, für Clients in WSDL verfügbar gemacht werden.

Definieren von Fehlerbedingungen, die Clients kennen sollten

SOAP-Fehler sind öffentlich beschriebene Nachrichten, die Fehlerinformationen für einen bestimmten Vorgang enthalten. Da sie zusammen mit anderen Vorgangsmeldungen in WSDL beschrieben sind, sind Clients darüber informiert und erwarten beim Aufrufen eines Vorgangs, dass sie diese ggf. verarbeiten müssen. Da WCF-Dienste jedoch in verwaltetem Code geschrieben werden, können Sie entscheiden, welche Fehlerbedingungen in verwaltetem Code in Fehler konvertiert und an den Client zurückgegeben werden sollen, um Fehlerbedingungen und Fehler in Ihrem Dienst von der formalen Fehlerunterhaltung zu trennen, die Sie mit einem Client haben.

Das folgende Codebeispiel zeigt z. B. einen Vorgang, der zwei ganze Zahlen akzeptiert und eine weitere ganze Zahl zurückgibt. Hier können mehrere Ausnahmen ausgelöst werden, daher müssen Sie beim Entwerfen des Fehlervertrags ermitteln, welche Fehlerbedingungen für Ihren Kunden wichtig sind. In diesem Fall sollte der Dienst die System.DivideByZeroException Ausnahme erkennen.

[ServiceContract]  
public class CalculatorService  
{  
    [OperationContract]
    int Divide(int a, int b)  
    {  
      if (b==0) throw new Exception("Division by zero!");  
      return a/b;  
    }  
}  

<ServiceContract> _
Public Class CalculatorService
    <OperationContract> _
    Public Function Divide(a As Integer, b As Integer) As Integer
        If b = 0 Then Throw New DivideByZeroException("Division by zero!")
        Return a / b
    End Function
End Class

Im vorherigen Beispiel kann der Vorgang entweder einen benutzerdefinierten SOAP-Fehler zurückgeben, der spezifisch für die Division durch Null ist, einen benutzerdefinierten Fehler, der spezifisch für mathematische Vorgänge ist, aber Informationen enthält, die spezifisch für die Aufteilung durch Null, mehrere Fehler für mehrere verschiedene Fehlersituationen oder gar keinen SOAP-Fehler sind.

Definieren des Inhalts von Fehlerbedingungen

Sobald eine Fehlerbedingung als eine identifiziert wurde, die einen benutzerdefinierten SOAP-Fehler nützlich zurückgeben kann, besteht der nächste Schritt darin, den Inhalt dieses Fehlers zu definieren und sicherzustellen, dass die Inhaltsstruktur serialisiert werden kann. Das Codebeispiel im vorherigen Abschnitt zeigt einen für einen Divide Vorgang spezifischen Fehler an. Wenn jedoch andere Vorgänge für den Calculator Dienst vorliegen, kann ein einzelner benutzerdefinierter SOAP-Fehler den Client über alle Rechnerfehlerbedingungen informieren, einschließlich Divide. Das folgende Codebeispiel zeigt die Erstellung des benutzerdefinierten SOAP-Fehlers MathFault. Dieser Fehler kann Fehler für alle mathematischen Operationen melden, auch für Divide. Während die Klasse einen Vorgang (die Operation Eigenschaft) und einen Wert angeben kann, der das Problem (die ProblemType Eigenschaft) beschreibt, muss die Klasse und diese Eigenschaften serialisierbar sein, um in einem benutzerdefinierten SOAP-Fehler auf den Client übertragen zu werden. Daher werden die Attribute System.Runtime.Serialization.DataContractAttribute und System.Runtime.Serialization.DataMemberAttribute verwendet, um den Typ und seine Eigenschaften serialisierbar und so interoperabel wie möglich zu machen.

// Define a math fault data contract
[DataContract(Namespace="http://Microsoft.ServiceModel.Samples")]
public class MathFault
{
    private string operation;
    private string problemType;

    [DataMember]
    public string Operation
    {
        get { return operation; }
        set { operation = value; }
    }

    [DataMember]
    public string ProblemType
    {
        get { return problemType; }
        set { problemType = value; }
    }
}

' Define a math fault data contract
<DataContract([Namespace]:="http://Microsoft.ServiceModel.Samples")> _
Public Class MathFault

    Private m_operation As String
    Private m_problemType As String

    <DataMember()> _
    Public Property Operation() As String

        Get

            Return m_operation

        End Get

        Set(ByVal value As String)

            m_operation = value

        End Set

    End Property

    <DataMember()> _
    Public Property ProblemType() As String

        Get

            Return m_problemType

        End Get

        Set(ByVal value As String)

            m_problemType = value

        End Set

    End Property

End Class

Weitere Informationen dazu, wie Sie sicherstellen, dass Ihre Daten serialisierbar sind, finden Sie unter Angeben der Datenübertragung in Serviceverträgen. Eine Liste der bereitgestellten Serialisierungsunterstützung System.Runtime.Serialization.DataContractSerializer finden Sie unter Typen, die vom Serialisierer für den Datenvertrag unterstützt werden.

Markieren von Operationen, um den Fehlervertrag einzurichten

Sobald eine serialisierbare Datenstruktur definiert ist, die als Teil eines benutzerdefinierten SOAP-Fehlers zurückgegeben wird, besteht der letzte Schritt darin, den Vorgangsvertrag als Auslösen eines SOAP-Fehlers dieses Typs zu kennzeichnen. Verwenden Sie dazu das System.ServiceModel.FaultContractAttribute Attribut, und übergeben Sie den Typ des benutzerdefinierten Datentyps, den Sie erstellt haben. Das folgende Codebeispiel zeigt, wie das FaultContractAttribute Attribut verwendet wird, um anzugeben, dass der Divide Vorgang einen SOAP-Fehler vom Typ MathFaultzurückgeben kann. Andere mathematische Vorgänge können nun auch angeben, dass sie ein MathFault zurückgeben können.

[OperationContract]
[FaultContract(typeof(MathFault))]
int Divide(int n1, int n2);

<OperationContract()> _
<FaultContract(GetType(MathFault))> _
Function Divide(ByVal n1 As Integer, ByVal n2 As Integer) As Integer

Ein Vorgang kann angeben, dass er mehr als einen benutzerdefinierten Fehler zurückgibt, indem er diesen Vorgang mit mehr als einem FaultContractAttribute Attribut markiert.

Der nächste Schritt zur Implementierung des Fehlervertrags in Ihrer Betriebsimplementierung wird im Thema Senden und Empfangen von Fehlern beschrieben.

Überlegungen zu SOAP, WSDL und Interoperabilität

Unter bestimmten Umständen, insbesondere bei der Zusammenarbeit mit anderen Plattformen, kann es wichtig sein, zu steuern, wie ein Fehler in einer SOAP-Nachricht angezeigt wird oder wie er in den WSDL-Metadaten beschrieben wird.

Das FaultContractAttribute Attribut verfügt über eine Name Eigenschaft, die die Steuerung des WSDL-Fehlerelementnamens zulässt, der in den Metadaten für diesen Fehler generiert wird.

Gemäß dem SOAP-Standard kann ein Fehler ein Action, ein Code und ein Reason enthalten. Das Action wird durch die Eigenschaft Action gesteuert. Die Code-Eigenschaft und die Reason-Eigenschaft sind beide Eigenschaften der System.ServiceModel.FaultException-Klasse, die die Basisklasse der generischen System.ServiceModel.FaultException<TDetail>-Klasse ist. Die Code Eigenschaft enthält ein SubCode Element.

Beim Zugriff auf Nichtdienste, die Fehler generieren, gibt es bestimmte Einschränkungen. WCF unterstützt nur Fehler mit Detailtypen, die das Schema beschreibt und mit Datenverträgen kompatibel sind. Wie oben erwähnt, unterstützt WCF beispielsweise keine Fehler, die XML-Attribute in ihren Detailtypen verwenden, oder Fehler mit mehr als einem Element der obersten Ebene im Detailabschnitt.

Siehe auch

  • Last updated on