2012-04-18 14 views
9

Dodałem usługę internetową w Visual Studio 2010 przy użyciu "Dodaj referencję usługi ...". Generuje to pewien kod w pliku o nazwie Reference.cs. Teraz, jeśli wezwę jedną z metod, nie będę wiedział, jakie wyjątki może wyrzucić metoda. Prawdopodobnie może wyrzucić wyjątki związane z siecią, takie jak SocketException lub IOException?Jakie wyjątki mogą generować wygenerowane odwołania do usługi?

Metody regularne w .NET mogą być sprawdzane na msdn lub wewnątrz kodu źródłowego, aby pokazać, jakie wyjątki mogą być rzucane, jak na przykład File.Open. Tutaj jest jasne, jakie wyjątki powinienem złapać i ponownie rzucić, aby wyświetlać komunikaty o błędach na późniejszym etapie.

W przypadku tych generowanych metod, skąd mogę wiedzieć, jakie wyjątki mogą powodować?

+0

dzięki za link. Wiem, jak odróżnić wyjątki, które powinny być chwytane, i wyjątki, które powinny się jednak bańki - stąd to pytanie. Jednak wygenerowany kod nie ma żadnego znacznika /// ani żadnych wskazówek dotyczących wyjątków, które mogą być zgłaszane. – vidstige

+0

Sprawdź następujące [wątku] [1] [1]: http://stackoverflow.com/questions/264747/finding-out-what-exceptions-a-method-might-throw-in- c-sharp – Tomtom

Odpowiedz

14

Istnieją "standardowe" wyjątki w tym przypadku i "niestandardowe" wyjątki (te zdefiniowane jako FaultContact s przez producenta usług i obecne w umowie o świadczenie usług).

W pierwszym przypadku Twoje obawy, przypuszczam, są następujące: CommunicationException i TimeoutException; są to udokumentowane możliwe wyjątki dla ICommunicationObject.BeginOpen i innych metod "otwierania" ICommunicationObject (base of the model). CommunicationObjectFaultedException jest udokumentowany dla metod "zamykania". Istnieje również QuotaExceededException dla metod, które wysyłają wiadomości, takie jak IRequestChannel.Request. Wśród many more that might be powinny być one wykrywalne.

Warto zauważyć, z artykułu MSDN połączonego powyżej, jest to:

Wszystkie wyjątki rzucane przez kanały muszą być albo System.TimeoutException, System.ServiceModel.CommunicationException, lub typ pochodzący z CommunicationException. (wyjątki takie jak ObjectDisposedException może być również rzucony, ale tylko do wskazania, że ​​ kod wywołujący nadużyła kanału. Jeśli kanał jest wykorzystywany poprawnie, musi tylko rzucić podanych wyjątków.)

Potem są "Błędy", które są wyjątkami podniesionymi po stronie usługi i (potencjalnie, jeśli włączone) są szczegółowe dla dzwoniącego, dzwoniący może wtedy obsłużyć to lub wyrzucić prawidłowy wyjątek od strony klienta:

Podczas generowania błąd, kanał niestandardowy nie powinien wysyłać usterki bezpośrednio bezpośrednio, raczej powinien zgłasza wyjątek i niech warstwa powyżej zdecyduje, czy przekonwertować ten wyjątek na błąd i jak wysłać go.

Kanał State oferuje wydarzenie Faulted do których można zapisać się być informowany, gdy taki stan osiągnął, a może działać. Domyślnie (bez konfiguracji tłumienia (?)) Usterki będą zgłaszane jako zarządzane wyjątki; ponownie, aby powtórzyć:

w klientach WCF, SOAP usterki występujące podczas komunikacji, które są zainteresowania do aplikacji klienckich są podniesione jako zarządzanych wyjątków. Chociaż istnieje wiele wyjątków, które mogą wystąpić podczas wykonywania dowolnego programu, aplikacje korzystające z modelu programowania klienta WCF mogą oczekiwać obsługi wyjątków dwóch [...] typów w wyniku komunikacji .

I this refers again do CommunicationException i TimeoutException wymienionych powyżej.

Wreszcie, przynajmniej na razie, jest nieoczekiwany:

FaultException wyjątki są wyrzucane gdy słuchacz otrzymuje usterkę że nie jest oczekiwane lub określonego w umowie pracy; Zwykle ma to miejsce, gdy debugowana jest aplikacja, a usługa ma ustawioną wartość true dla usługi dla .

+0

świetna odpowiedź z referencjami i wszystkim! Naprawdę polubiłem pierwszy cytat. Idealnie odpowiedział na moje pytanie - powinienem złapać CommunicationException i niech reszta bąka, ponieważ wskazują one (lub wygenerowany kod) niewłaściwie wykorzystują metody kanału. – vidstige

Powiązane problemy