Określanie i obsługa błędów w kontraktach i usługach
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ługi komunikują się z przetwarzaniem informacji o błędach przy użyciu komunikatów o błędach protokołu 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 współdziałanie systemu typów, którego klienci na dowolnej platformie SOAP mogą używać, 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. Błędy protokołu SOAP niezdecydowane nie są określone w umowie dotyczącej 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ż zwrócenie w błędzie protokołu SOAP tylko informacji, które klient musi wiedzieć, aby zminimalizować ujawnienie informacji.
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ć nierejestrowanych błędów mydła do celów debugowania i mogą rozszerzać domyślne zachowanie 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 Calculator usługa, bardziej ogólny MathFault błąd protokołu SOAP może być w stanie 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 w przypadku usługi (lub klienta dwustronnego) wysyłania niezdeklarowanego błędu protokołu SOAP, który nie jest wymieniony w języku WSDL (Web Services Description Language) dla tej operacji. Na przykład podczas tworzenia usługi mogą wystąpić nieoczekiwane sytuacje, w których przydatne jest debugowanie informacji z powrotem do klienta. Ponadto można ustawić ServiceBehaviorAttribute.IncludeExceptionDetailInFaults właściwość lub ServiceDebugBehavior.IncludeExceptionDetailInFaults właściwość, aby true umożliwić klientom programu WCF uzyskiwanie informacji o wyjątkach operacji usługi wewnętrznej. 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żne
Ponieważ wyjątki zarządzane mogą uwidaczniać informacje o aplikacji wewnętrznej, ustawienie ServiceBehaviorAttribute.IncludeExceptionDetailInFaults lub ServiceDebugBehavior.IncludeExceptionDetailInFaultstrue zezwalać klientom WCF na uzyskiwanie informacji o wyjątkach operacji usługi wewnętrznej, w tym danych osobowych lub innych poufnych informacji.
W związku z tym ustawienie lub ServiceDebugBehavior.IncludeExceptionDetailInFaults ustawienie ServiceBehaviorAttribute.IncludeExceptionDetailInFaults jest true zalecane tylko jako sposób tymczasowego debugowania aplikacji usługi. Ponadto język WSDL dla metody zwracającej nieobsługiwane wyjątki zarządzane w ten sposób nie zawiera kontraktu FaultException<TDetail>ExceptionDetailtypu . 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 kontraktów błędów w kolejności alfabetycznej dla 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 akcji. 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. Ponadto jeśli zdefiniowano wiele powiązanych kontraktów błędów pochodzących z udostępnionej klasy bazowej, pamiętaj, aby oznaczyć wszystkie nowe elementy członkowskie za pomocą polecenia [DataMember(IsRequired=true)]. Aby uzyskać więcej informacji na temat tego IsRequired atrybutu, DataMemberAttributezobacz . Uniemożliwi to klasę bazową jako zgodny typ i wymusi deserializacji błędu do poprawnego typu pochodnego.