Owijanie usługi WWW w bloku prób/catch

Question

Czy najlepiej jest zawijać metodę/wywołanie usługi sieci Web w bloku try/catch?

Czy żądania serwisów internetowych nie są powodem awarii aplikacji komputerowych .NET? Więc myślałem, że wszystkie połączenia powinny być pakowane w try/catch, aby temu zapobiec.

Dobry pomysł?

Ponadto, czy powinien on rzucić wyjątek lub po prostu mieć pusty haczyk?

Answer 1

Zakładam, że używasz WCF, ponieważ twoje pytanie jest z nim oznaczone. Dobrą praktyką w obsłudze wyjątków w WFC nie jest dopuszczanie wyjątków do przepychania się przez przewód do konsumenta, ale zamiast tego rzucanie znaczących Wyników błędów.

Powinieneś zawsze spróbować ... catch block w twojej operacji, jeśli jest jakaś szansa, że ​​może być przez niego wygenerowany wyjątek. Jeśli zezwolisz na bańkę wstępną, mogą powstać tylko dwa scenariusze: Jeśli skonfigurowałeś swoją usługę, aby zezwalać na wyjątki w błędach, ujawnisz wewnętrzne usługi otwierania się dla bezpieczeństwa. Lub nie masz tego skonfigurowanego w swojej usłudze, a konsument otrzymuje bardzo ogólny komunikat, który wskazuje, że coś poszło nie tak, co nie jest bardzo przydatne dla nich lub zespołu wsparcia.

Należy zadeklarować jeden lub więcej Wyrażeń FaultExceptions, w zależności od tego, jakie wiadomości mają być odbierane przez użytkownika z Twojej operacji, udekoruj je jako FaultContracts w deklaracji operacji. Następnie możesz spróbować ... uchwycić określone wyjątki i rzucić określone Usterki. Możesz także spróbować ... złapać wyjątek odłowu i rzucić bardzo ogólny błąd.

Kluczem tutaj nie jest ujawnianie zbyt dużej ilości informacji o tym, co dzieje się z Twoją operacją wewnętrznie - szczególnie ślady stosu!

Usterka jest tylko kolejną umową dotyczącą danych, dlatego jest deklarowana w pliku WSDL. Oznacza to, że konsument może wykryć usterkę w sposób szczególny i może reagować na usterki generowane przez operację, tak jakby był to wyjątek wyrzucony z ich kodu.

Mam nadzieję, że to pomoże.

Joe.

Answer 2

Jest to przypadek, który może spowodować zgłoszenie wyjątku, więc należy go zapakować w blok catch catch.

Co zrobić z obsługi wyjątków to zależy od programu sterującego ...

Answer 3

Wykorzystanie metody usługi sieci web w bloku try catch jest dobrym pomysłem, jak pan stwierdził, że nie chcesz upaść powołanie aplikacja, ponieważ coś poszło nie tak w metodzie usługi sieciowej.

Ponadto, zamiast odrzucać wyjątek do klienta, który i tak nie może nic z tym zrobić, możesz rozważyć, że wszystkie metody usługi sieci Web zwrócą strukturę lub małą klasę, która może zawierać status połączenia. , kod błędu i przyjazny komunikat, który może wyjaśnić błąd.

Answer 4

Tak, powinieneś zawijać Web service call w try-catch. NIE używaj pustego haczyka, ponieważ one (w większości) są czystym złem. Twój blok catch powinien przynajmniej logować wyjątek. Nie wiem o logice aplikacji, ale prawdopodobnie komunikat (np. "Informacja z usługi nie został pobrany z powodu błędu technicznego") powinien zostać wyświetlony użytkownikowi.

Answer 5

Jest ok, ale spróbuj po prostu wychwycić typy wyjątków, z którymi możesz sobie poradzić.

Należy unikać przechwytywania jakichkolwiek "wyjątków" lub, jeśli to możliwe, rejestrować i/lub ostrzegać użytkownika i/lub ponawiać próbę połączenia z serwisem internetowym.

Jeśli jest to aplikacja formularzy systemu Windows, zazwyczaj zawijam ostatni "wyjątek" w bloku #if DEBUG, aby uniknąć ukrywania wyjątków podczas debugowania lub testowania.

#if !DEBUG 
catch (Exception ex) 
{ 
    // show messagebox, log, etc 
} 
#endif 

Answer 6

using System; 
using System.ServiceModel; 
using Entities; //my entities 
using AuthenticationService; //my webservice reference 

namespace Application.SL.Model 
{ 
    public class AuthenticationServiceHelper 
    { 
     /// <summary> 
     /// User log in 
     /// </summary> 
     /// <param name="callback"></param> 
     public void UserLogIn(Action<C48PR01IzhodOut, Exception> callback) 
     { 
      var proxy = new AuthenticationServiceClient(); 

     try 
     { 
      proxy.UserLogInCompleted += (sender, eventargs) => 
      { 
       var userCallback = eventargs.UserState as Action<C48PR01IzhodOut, Exception>; 
       if (userCallback == null) 
        return; 

       if (eventargs.Error != null) 
       { 
        userCallback(null, eventargs.Error); 
        return; 
       } 
       userCallback(eventargs.Result, null); 
      }; 
      proxy.UserLogInAsync(callback); 
     } 
     catch (Exception ex) 
     { 
      proxy.Abort(); 
      ErrorHelper.WriteErrorLog(ex.ToString()); 
     } 
     finally 
     { 
      if (proxy.State != CommunicationState.Closed) 
      { 
       proxy.CloseAsync(); 
      } 
     } 
     } 
} 

Czy to dobra praktyka, czy jest miejsce na poprawę?