Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Aplikacje programu Windows Communication Foundation (WCF) obsługują sytuacje błędów przez mapowanie zarządzanych obiektów wyjątków na obiekty błędów protokołu SOAP i obiekty błędów protokołu SOAP do zarządzanych obiektów wyjątków. W tematach w tej sekcji omówiono sposób projektowania kontraktów w celu uwidaczniania warunków błędów jako niestandardowych błędów protokołu SOAP, sposobu zwracania takich błędów w ramach implementacji usługi oraz sposobu, w jaki klienci przechwytują takie błędy.
Omówienie obsługi błędów
We wszystkich zarządzanych aplikacjach błędy przetwarzania są reprezentowane przez Exception obiekty. W aplikacjach opartych na protokole SOAP, takich jak aplikacje WCF, metody usług przekazują informacje o błędach przetwarzania za pomocą komunikatów błędów SOAP. Błędy protokołu SOAP to typy komunikatów, które są zawarte w metadanych dla operacji usługi, a tym samym tworzą kontrakt błędów, którego klienci mogą używać, aby ich działanie było bardziej niezawodne lub interaktywne. Ponadto, ponieważ błędy protokołu SOAP są wyrażane dla klientów w postaci XML, jest to wysoce interoperacyjny system typów, który mogą stosować klienci na dowolnej platformie SOAP, zwiększając zasięg aplikacji WCF.
Ponieważ aplikacje WCF działają w obu typach systemów błędów, wszelkie zarządzane informacje o wyjątkach wysyłane do klienta muszą być konwertowane z wyjątków na błędy protokołu SOAP w usłudze, wysyłane i konwertowane z błędów protokołu SOAP na wyjątki błędów w klientach WCF. W przypadku klientów dwukierunkowych kontrakty klienta mogą również wysyłać błędy protokołu SOAP z powrotem do usługi. W obu przypadkach możesz użyć domyślnych zachowań wyjątków usługi lub jawnie kontrolować, czy —i jak — wyjątki są mapowane na komunikaty o błędach.
Można wysłać dwa typy błędów protokołu SOAP: zadeklarowane i niezadeklarowane. Zadeklarowane błędy protokołu SOAP to te, w których operacja ma System.ServiceModel.FaultContractAttribute atrybut określający niestandardowy typ błędu PROTOKOŁU SOAP. Niezadeklarowane błędy SOAP nie są określone w kontrakcie dla operacji.
Zdecydowanie zaleca się, aby operacje usługi deklarowały swoje błędy przy użyciu atrybutu FaultContractAttribute , aby formalnie określić wszystkie błędy protokołu SOAP, których klient może oczekiwać w normalnym przebiegu operacji. Zaleca się również zwracanie w błędzie SOAP tylko tych informacji, które są niezbędne dla klienta, aby zminimalizować ryzyko ujawnienia danych.
Zazwyczaj usługi (i klienci dwukierunkowi) wykonują następujące kroki, aby pomyślnie zintegrować obsługę błędów z aplikacjami:
Mapuj warunki wyjątku na niestandardowe błędy protokołu SOAP.
Klienci i usługi wysyłają i odbierają błędy protokołu SOAP jako wyjątki.
Ponadto klienci i usługi WCF mogą używać niezadeklarowanych błędów SOAP do celów debugowania i mogą rozszerzać domyślne mechanizmy obsługi błędów. W poniższych sekcjach omówiono te zadania i pojęcia.
Mapuj wyjątki do błędów protokołu SOAP
Pierwszym krokiem tworzenia operacji obsługującej warunki błędu jest podjęcie decyzji, w jakich warunkach aplikacja kliencka powinna zostać poinformowana o błędach. Niektóre operacje mają warunki błędów specyficzne dla ich funkcjonalności. Na przykład PurchaseOrder operacja może zwrócić określone informacje klientom, którzy nie mogą już inicjować zamówienia zakupu. W innych przypadkach, takich jak usługa Calculator, bardziej ogólny błąd SOAP MathFault może opisać wszystkie warunki błędu w całej usłudze. Po zidentyfikowaniu warunków błędu klientów usługi można skonstruować niestandardową usterkę protokołu SOAP, a operację można oznaczyć jako zwracającą tę usterkę protokołu SOAP, gdy wystąpi odpowiedni warunek błędu.
Aby uzyskać więcej informacji na temat tego kroku tworzenia usługi lub klienta, zobacz Definiowanie i określanie błędów.
Klienci i usługi obsługują błędy protokołu SOAP jako wyjątki
Identyfikowanie warunków błędu operacji, definiowanie niestandardowych błędów protokołu SOAP i oznaczanie tych operacji jako zwracania tych błędów to pierwsze kroki w pomyślnej obsłudze błędów w aplikacjach WCF. Następnym krokiem jest prawidłowe zaimplementowanie wysyłania i odbierania tych błędów. Zazwyczaj usługi wysyłają błędy, aby poinformować aplikacje klienckie o warunkach błędu, ale klienci dwukierunkowi mogą również wysyłać błędy protokołu SOAP do usług.
Aby uzyskać więcej informacji, zobacz Wysyłanie i odbieranie błędów.
Niezadeklarowane błędy protokołu SOAP i debugowanie
Zadeklarowane błędy protokołu SOAP są niezwykle przydatne do tworzenia niezawodnych, współdziałalnych, rozproszonych aplikacji. Jednak w niektórych przypadkach jest to przydatne dla usługi (lub klienta dwukierunkowego) do wysyłania niezdeklarowanego błędu protokołu SOAP, który nie jest wymieniony w języku opisu usług internetowych (WSDL) dla tej operacji. Na przykład, podczas tworzenia usługi mogą wystąpić nieoczekiwane sytuacje, w których przydatne jest dla celów debugowania wysłanie informacji z powrotem do klienta. Ponadto można ustawić ServiceBehaviorAttribute.IncludeExceptionDetailInFaults właściwość lub ServiceDebugBehavior.IncludeExceptionDetailInFaults właściwość na true, aby umożliwić klientom WCF uzyskiwanie informacji o wyjątkach operacji wewnętrznych usługi. Zarówno wysyłanie pojedynczych błędów, jak i ustawianie właściwości zachowania debugowania opisano w temacie Wysyłanie i odbieranie błędów.
Ważna
Ponieważ wyjątki zarządzane mogą ujawniać informacje wewnętrzne aplikacji, ustawienie ServiceBehaviorAttribute.IncludeExceptionDetailInFaults lub ServiceDebugBehavior.IncludeExceptionDetailInFaults na true zezwala klientom WCF na uzyskiwanie informacji o wyjątkach związanych z operacjami wewnętrznej usługi, w tym danych osobowych lub innych informacji poufnych.
Dlatego zaleca się ustawienie ServiceBehaviorAttribute.IncludeExceptionDetailInFaults lub ServiceDebugBehavior.IncludeExceptionDetailInFaults na true tylko jako sposób na tymczasowe debugowanie aplikacji usługowej. W dodatku WSDL dla metody, która zwraca nieobsługiwane, zarządzane wyjątki w ten sposób, nie zawiera kontraktu dla FaultException<TDetail> typu ExceptionDetail. Klienci muszą oczekiwać możliwości wystąpienia nieznanego błędu protokołu SOAP (zwróconego do klientów programu WCF jako System.ServiceModel.FaultException obiektów), aby prawidłowo uzyskać informacje o debugowaniu.
Dostosowywanie obsługi błędów za pomocą programu IErrorHandler
Jeśli masz specjalne wymagania dotyczące dostosowywania komunikatu odpowiedzi do klienta w przypadku wystąpienia wyjątku na poziomie aplikacji lub wykonania niestandardowego przetwarzania po zwracaniu komunikatu odpowiedzi, zaimplementuj System.ServiceModel.Dispatcher.IErrorHandler interfejs.
Problemy z serializacji błędów
Podczas deserializacji kontraktu błędów program WCF najpierw próbuje dopasować nazwę kontraktu błędów w komunikacie PROTOKOŁU SOAP z typem kontraktu błędów. Jeśli nie może znaleźć dokładnego dopasowania, będzie przeszukiwać listę dostępnych umów dotyczących błędów w kolejności alfabetycznej, szukając zgodnego typu. Jeśli dwa kontrakty błędów są zgodnymi typami (jeden jest podklasą innej, na przykład), niewłaściwy typ może służyć do anulowania serializacji błędu. Dzieje się tak tylko wtedy, gdy kontrakt błędu nie określa nazwy, przestrzeni nazw i działania. Aby zapobiec wystąpieniu tego problemu, należy zawsze w pełni kwalifikować kontrakty błędów, określając nazwy, przestrzeń nazw i atrybuty akcji. Jeżeli ponadto zdefiniowano wiele powiązanych kontraktów błędów pochodzących ze wspólnej klasy bazowej, pamiętaj, aby oznaczyć wszystkie nowe członkowie za pomocą polecenia [DataMember(IsRequired=true)]. Aby uzyskać więcej informacji na temat tego IsRequired atrybutu, DataMemberAttributezobacz . Zapobiegnie to traktowaniu klasy bazowej jako zgodnego typu i wymusi zdeserializowanie błędu do poprawnego typu pochodnego.