Udostępnij przez

Definiowanie i określanie błędów

Błędy protokołu SOAP przekazują informacje o stanie błędu z usługi do klienta, a w przypadku komunikacji dwukierunkowej od klienta do usługi w sposób zapewniający interoperacyjność. W tym temacie omówiono, kiedy i jak zdefiniować niestandardową zawartość błędów i określić, które operacje mogą je zwrócić. Aby uzyskać więcej informacji na temat tego, jak usługa lub klient dwustronny może wysyłać te błędy oraz w jaki sposób klient lub aplikacja usługi obsługuje te błędy, zobacz Wysyłanie i odbieranie błędów. Aby zapoznać się z omówieniem obsługi błędów w aplikacjach programu Windows Communication Foundation (WCF), zobacz Określanie i obsługa błędów w kontraktach i usługach.

Przegląd

Zadeklarowane błędy protokołu SOAP to te, w których operacja ma określony niestandardowy typ błędu SOAP. Błędy SOAP niewymienione to te, które nie zostały określone w kontrakcie dla operacji. Ten temat ułatwia zidentyfikowanie tych warunków błędu i utworzenie kontraktu błędów dla usługi, którego klienci mogą używać do prawidłowego obsługi tych warunków błędu, gdy są powiadamiane przez niestandardowe błędy protokołu SOAP. Podstawowe zadania są w następującej kolejności:

  1. Zdefiniuj warunki błędu, o których powinien wiedzieć klient usługi.

  2. Określ niestandardową zawartość błędów protokołu SOAP dla tych przypadków błędów.

  3. Oznacz operacje tak, aby określone błędy protokołu SOAP, które zgłaszają, były widoczne dla klientów w języku WSDL.

Definiowanie warunków błędów, o których powinni wiedzieć klienci

Komunikaty błędów protokołu SOAP są publicznie opisywane i zawierają informacje o błędach dla konkretnej operacji. Ponieważ są one opisane wraz z innymi komunikatami operacji w języku WSDL, klienci wiedzą i dlatego oczekują obsługi takich błędów podczas wywoływania operacji. Jednak ponieważ usługi WCF są napisane w kodzie zarządzanym, podjęcie decyzji, które warunki błędu w kodzie zarządzanym mają zostać przekonwertowane na błędy i zwrócone klientowi, daje możliwość oddzielenia warunków błędów i usterek w usłudze od formalnej rozmowy o błędzie z klientem.

Na przykład poniższy przykład kodu przedstawia operację, która przyjmuje dwie liczby całkowite i zwraca inną liczbę całkowitą. W tym miejscu można zgłosić kilka wyjątków, dlatego podczas projektowania kontraktu błędów należy określić, które warunki błędu są ważne dla klienta. W takim przypadku usługa powinna wykryć System.DivideByZeroException wyjątek.

[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

W poprzednim przykładzie operacja może zwrócić niestandardową usterkę protokołu SOAP specyficzną dla dzielenia przez zero, niestandardową usterkę specyficzną dla operacji matematycznych, ale zawierającą informacje specyficzne dla dzielenia przez zero, wiele błędów w kilku różnych sytuacjach błędów lub w ogóle brak błędu protokołu SOAP.

Definiowanie zawartości warunków błędów

Po zidentyfikowaniu warunku błędu jako warunku, który może użytecznie zwrócić niestandardowy błąd SOAP, następnym krokiem jest zdefiniowanie zawartości tego błędu i upewnienie się, że struktura zawartości może być zserializowana. Przykładowy kod w poprzedniej sekcji przedstawia błąd specyficzny dla operacji Divide, ale jeśli w usłudze istnieją inne operacje na Calculator, pojedynczy niestandardowy błąd SOAP może poinformować klienta o wszystkich warunkach błędu kalkulatora, w tym o Divide. Poniższy przykład kodu przedstawia tworzenie niestandardowego błędu protokołu SOAP, MathFaultktóry może zgłaszać błędy wykonywane przy użyciu wszystkich operacji matematycznych, w tym Divide. Klasa może określić operację (Operation właściwość) i wartość opisującą problem (ProblemType właściwość), klasa i te właściwości muszą być serializowalne, aby mogły być przeniesione do klienta w niestandardowym błędzie protokołu SOAP. System.Runtime.Serialization.DataContractAttribute i System.Runtime.Serialization.DataMemberAttribute atrybuty są używane do uczynienia typu i jego właściwości serializowalnymi i tak interoperacyjnymi jak to tylko możliwe.

// 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

Aby uzyskać więcej informacji na temat sposobu serializacji danych, zobacz Określanie transferu danych w kontraktach usług. Aby uzyskać listę obsługi serializacji zapewnianej przez System.Runtime.Serialization.DataContractSerializer, zobacz Typy obsługiwane przez serializator kontraktu danych.

Operacje znakowania w celu ustanowienia kontraktu na błędy

Po zdefiniowaniu struktury danych możliwej do serializacji, która jest zwracana w ramach niestandardowego błędu protokołu SOAP, ostatnim krokiem jest oznaczenie kontraktu operacji jako zgłaszający błąd SOAP tego typu. W tym celu należy użyć atrybutu System.ServiceModel.FaultContractAttribute i przekazać typ utworzonego typu danych niestandardowych. Poniższy przykład kodu pokazuje, jak użyć atrybutu FaultContractAttribute , aby określić, że Divide operacja może zwrócić błąd PROTOKOŁU SOAP typu MathFault. Inne operacje oparte na matematyce mogą teraz również określać, że mogą zwracać wartość MathFault.

[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

Operacja może określać, że zwraca więcej niż jeden błąd niestandardowy, oznaczając tę operację więcej niż jednym FaultContractAttribute atrybutem.

Następny krok, czyli zaimplementowanie kontraktu błędów w implementacji operacji, opisano w sekcji Wysyłanie i odbieranie błędów.

Zagadnienia dotyczące interoperacyjności SOAP, WSDL i rozważania dotyczące interoperacyjności.

W niektórych okolicznościach, zwłaszcza w przypadku współdziałania z innymi platformami, może być ważne, aby kontrolować sposób, w jaki błąd pojawia się w komunikacie PROTOKOŁU SOAP lub sposób, w jaki został opisany w metadanych WSDL.

Atrybut FaultContractAttribute ma Name właściwość, która umożliwia sterowanie nazwą elementu błędu WSDL wygenerowaną w metadanych dla tego błędu.

Zgodnie ze standardem SOAP, błąd może mieć Action, Code i Reason. Action jest kontrolowany przez właściwość Action. Właściwości Code i Reason są właściwościami klasy System.ServiceModel.FaultException, która jest klasą nadrzędną ogólnego System.ServiceModel.FaultException<TDetail>. Właściwość Code zawiera element członkowski SubCode .

Podczas uzyskiwania dostępu do nie-usług, które generują błędy, istnieją pewne ograniczenia. Program WCF obsługuje tylko błędy ze szczegółowymi typami, które opisano w schemacie i które są zgodne z kontraktami danych. Na przykład, jak wspomniano powyżej, WCF nie obsługuje błędów, które w swoich typach szczegółów wykorzystują atrybuty XML, lub błędów zawierających więcej niż jeden element najwyższego poziomu w sekcji szczegółów.

Zobacz także

  • Last updated on