Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Anwendungen der Windows Communication Foundation (WCF) behandeln Fehlersituationen, indem sie verwaltete Ausnahmeobjekte mit SOAP-Fehlerobjekten abbilden und umgekehrt. In den Themen in diesem Abschnitt wird erläutert, wie Verträge entwerfen, um Fehlerbedingungen als benutzerdefinierte SOAP-Fehler verfügbar zu machen, wie solche Fehler als Teil der Dienstimplementierung zurückgegeben werden und wie Clients solche Fehler abfangen.
Übersicht über die Fehlerbehandlung
In allen verwalteten Anwendungen werden Verarbeitungsfehler durch Exception Objekte dargestellt. In SOAP-basierten Anwendungen wie WCF-Anwendungen kommunizieren Dienstmethoden die Verarbeitung von Fehlerinformationen mithilfe von SOAP-Fehlermeldungen. SOAP-Fehler sind Nachrichtentypen, die in den Metadaten für einen Dienstvorgang enthalten sind und daher einen Fehlervertrag erstellen, den Clients verwenden können, um ihren Vorgang robuster oder interaktiver zu machen. Da SOAP-Fehler für Clients in XML-Form ausgedrückt werden, handelt es sich um ein hoch interoperables Typsystem, das Clients auf jeder SOAP-Plattform verwenden können, wodurch die Reichweite Ihrer WCF-Anwendung erhöht wird.
Da WCF-Anwendungen unter beiden Arten von Fehlersystemen ausgeführt werden, müssen alle verwalteten Ausnahmeinformationen, die an den Client gesendet werden, von Ausnahmen in SOAP-Fehler im Dienst konvertiert, gesendet und von SOAP-Fehlern in Fehler exceptions in WCF-Clients konvertiert werden. Bei Duplexclients können Clientverträge auch SOAP-Fehler an einen Dienst senden. In beiden Fällen können Sie das Standardverhalten von Dienstausnahmen verwenden oder explizit kontrollieren, ob – und wie – Ausnahmen Fehlermeldungen zugeordnet werden.
Zwei Arten von SOAP-Fehlern können gesendet werden: deklariert und nicht deklariert. Deklarierte SOAP-Fehler sind diejenigen, in denen ein Vorgang über ein System.ServiceModel.FaultContractAttribute Attribut verfügt, das einen benutzerdefinierten SOAP-Fehlertyp angibt. Undeklarierte SOAP-Fehler werden im Vertrag für einen Vorgang nicht angegeben.
Es wird dringend empfohlen, dass Dienstvorgänge ihre Fehler mithilfe des FaultContractAttribute Attributs deklarieren, um formal alle SOAP-Fehler anzugeben, die ein Client im normalen Verlauf eines Vorgangs erwarten kann. Es wird auch empfohlen, dass Sie in einem SOAP-Fehler nur die Informationen zurückgeben, die ein Client wissen muss, um die Offenlegung von Informationen zu minimieren.
In der Regel führen Dienste (und Duplexclients) die folgenden Schritte aus, um die Fehlerbehandlung erfolgreich in ihre Anwendungen zu integrieren:
Zuordnen von Ausnahmebedingungen zu benutzerdefinierten SOAP-Fehlern.
Clients und Dienste senden und empfangen SOAP-Fehler als Ausnahmen.
Darüber hinaus können WCF-Clients und -Dienste nicht deklarierte Soap-Fehler für Debuggingzwecke verwenden und das Standardfehlerverhalten erweitern. In den folgenden Abschnitten werden diese Aufgaben und Konzepte erläutert.
Zuordnung von Ausnahmen zu SOAP-Fehlern
Der erste Schritt beim Erstellen eines Vorgangs, der Fehlerbedingungen behandelt, besteht darin, zu entscheiden, unter welchen Bedingungen eine Clientanwendung über Fehler informiert werden sollte. Einige Vorgänge weisen Fehlerbedingungen auf, die für ihre Funktionalität spezifisch sind. Ein PurchaseOrder-Vorgang kann beispielsweise spezifische Informationen für Kunden zurückgeben, die keine Bestellung mehr initiieren dürfen. In anderen Fällen, z. B. einem Calculator Dienst, kann ein allgemeinerer MathFault SOAP-Fehler alle Fehlerbedingungen für einen gesamten Dienst beschreiben. Sobald die Fehlerbedingungen von Clients Ihres Diensts identifiziert wurden, kann ein benutzerdefinierter SOAP-Fehler erstellt werden, und der Vorgang kann als Rückgabe dieses SOAP-Fehlers gekennzeichnet werden, wenn die entsprechende Fehlerbedingung auftritt.
Weitere Informationen zu diesem Schritt zur Entwicklung Ihres Diensts oder Clients finden Sie unter Definieren und Angeben von Fehlern.
Clients und Dienste behandeln SOAP-Fehler als Ausnahmen
Die Identifizierung von Vorgangsfehlerbedingungen, das Definieren von benutzerdefinierten SOAP-Fehlern und das Markieren dieser Vorgänge als Rückgabe dieser Fehler sind die ersten Schritte bei der erfolgreichen Fehlerbehandlung in WCF-Anwendungen. Der nächste Schritt besteht darin, das Senden und Empfangen dieser Fehler ordnungsgemäß zu implementieren. In der Regel senden Dienste Fehler, um Clientanwendungen über Fehlerbedingungen zu informieren, duplexclients können jedoch auch SOAP-Fehler an Dienste senden.
Weitere Informationen finden Sie unter Senden und Empfangen von Fehlern.
Nicht deklarierte SOAP-Fehler und Debugging
Deklarierte SOAP-Fehler sind äußerst nützlich für die Erstellung robuster, interoperabler, verteilter Anwendungen. In einigen Fällen ist es jedoch nützlich, dass ein Dienst (oder Duplexclient) einen nicht deklarierten SOAP-Fehler sendet, einer, der in der Web Services Description Language (WSDL) für diesen Vorgang nicht erwähnt wird. Wenn Sie beispielsweise einen Dienst entwickeln, können unerwartete Situationen auftreten, in denen es für Debuggingzwecke nützlich ist, Informationen an den Client zurückzusenden. Darüber hinaus können Sie die ServiceBehaviorAttribute.IncludeExceptionDetailInFaults-Eigenschaft oder die ServiceDebugBehavior.IncludeExceptionDetailInFaults-Eigenschaft so festlegen, dass WCF-Clients Informationen über interne Dienstvorgangsausnahmen abrufen können. Sowohl das Senden einzelner Fehler als auch das Festlegen der Debugverhaltenseigenschaften werden in "Senden" und "Empfangen von Fehlern" beschrieben.
Von Bedeutung
Da verwaltete Ausnahmen interne Anwendungsinformationen offenlegen können, kann das Festlegen von ServiceBehaviorAttribute.IncludeExceptionDetailInFaults oder ServiceDebugBehavior.IncludeExceptionDetailInFaults auf true WCF-Clients ermöglichen, Informationen über Ausnahmen von internen Dienstvorgängen abzurufen, einschließlich persönlich identifizierbarer oder anderer vertraulicher Informationen.
Daher wird empfohlen, ServiceBehaviorAttribute.IncludeExceptionDetailInFaults oder ServiceDebugBehavior.IncludeExceptionDetailInFaults auf true zu setzen, um eine Dienstanwendung vorübergehend zu debuggen. Darüber hinaus enthält die WSDL für eine Methode, die nicht behandelte verwaltete Ausnahmen auf diese Weise zurückgibt, nicht den Vertrag für FaultException<TDetail> des Typs ExceptionDetail. Clients müssen auf die Möglichkeit von unbekannten SOAP-Fehlern vorbereitet sein, die an WCF-Clients als System.ServiceModel.FaultException-Objekte zurückgegeben werden, damit sie die Debuginformationen korrekt abrufen können.
Anpassen der Fehlerbehandlung mit IErrorHandler
Wenn Sie spezielle Anforderungen haben, um die Antwortnachricht entweder an den Client anzupassen, wenn eine Ausnahme auf Anwendungsebene auftritt oder eine benutzerdefinierte Verarbeitung nach der Rückgabe der Antwortnachricht durchführt, implementieren Sie die System.ServiceModel.Dispatcher.IErrorHandler Schnittstelle.
Fehler bei der Serialisierung
Beim Deserialisieren eines Fehlervertrags versucht WCF zunächst, den Fehlervertragsnamen in der SOAP-Nachricht mit dem Fehlervertragstyp abzugleichen. Wenn eine genaue Übereinstimmung nicht gefunden werden kann, wird die Liste der verfügbaren Fehlerverträge in alphabetischer Reihenfolge nach einem kompatiblen Typ durchsucht. Wenn zwei Fehlerverträge kompatible Typen sind (z. B. eine Unterklasse einer anderen), kann der falsche Typ verwendet werden, um den Fehler zu de serialisieren. Dies tritt nur auf, wenn der Fehlervertrag keinen Namen, Namespace und Aktion angibt. Um zu verhindern, dass dieses Problem auftritt, qualifizieren Sie fehlerverträge immer vollständig, indem Sie den Namen, den Namespace und die Aktionsattribute angeben. Wenn Sie außerdem eine Reihe verwandter Fehlerverträge definiert haben, die von einer freigegebenen Basisklasse abgeleitet sind, müssen Sie alle neuen Member mit [DataMember(IsRequired=true)]markieren. Weitere Informationen zu diesem IsRequired Attribut finden Sie unter DataMemberAttribute. Dadurch wird verhindert, dass eine Basisklasse ein kompatibler Typ ist und erzwingt, dass der Fehler in den richtigen abgeleiteten Typ deserialisiert wird.