Come avvolgere un servizio Web nel blocco try/catch

Question

È consigliabile racchiudere un metodo/chiamata di servizio Web in un blocco try/catch?

Io non richieste di servizi web tendono ad essere la ragione per cui l'incidente applicazioni .NET per desktop? Quindi stavo pensando che tutte le chiamate dovrebbero essere racchiuse in try/catch per evitare questo.

Buona idea?

Inoltre, dovrebbe generare un'eccezione o semplicemente avere una cattura vuoto?

Answer 1

Suppongo che si stia utilizzando WCF, poiché la domanda è contrassegnata con esso. Una buona pratica nella gestione delle eccezioni con WFC non consente alle eccezioni di diffondersi in tutto il cavo verso il consumatore, ma lancia invece FaultException significative.

Si dovrebbe sempre provare ... catturare il blocco nelle operazioni se esiste la possibilità che venga generata un'eccezione. Se si consente la bolla di approvazione, possono verificarsi solo due scenari: Se il servizio è stato configurato per consentire dettagli delle eccezioni negli errori, si espongono i componenti interni del servizio che si aprono per violazioni della sicurezza. Oppure non hai configurato questo nel tuo servizio e il consumatore riceve un messaggio molto generico che indica che qualcosa è andato storto, il che non è molto utile per loro o per il team di supporto.

Quello che dovresti fare è dichiarare una o più FaultException, a seconda di quali messaggi vuoi che l'utente riceva dall'operazione, decorandoli come FaultContracts sulla dichiarazione di operazione. Quindi puoi provare ... catturare eccezioni specifiche e generare errori specifici. Puoi anche provare ... cattura che cattura un'eccezione e genera un errore molto generale.

La chiave qui, non sta rivelando troppe informazioni di ciò che sta accadendo con l'operazione internamente - specialmente tracce dello stack!

L'errore è solo un altro contratto di dati, quindi è dichiarato nel WSDL. Ciò significa che il consumatore può individuare l'errore in modo specifico e può reagire ai guasti generati dall'operazione come se si trattasse di un'eccezione generata dal codice.

Spero che questo aiuti.

Joe.

Answer 2

Questo è un caso che potrebbe provocare un'eccezione essere gettato, quindi sì, deve essere avvolto in un blocco try catch.

Cosa fare con il gestore di eccezioni dipende dalla logica di programma ...

Answer 3

Mettere un metodo di servizio Web in un blocco try cattura è una buona idea, come lei ha dichiarato che non vuoi mandare in crash il chiamante applicazione perché qualcosa è andato storto nel metodo di servizio web.

Inoltre, anziché restituire un'eccezione al client, che comunque non può fare nulla al riguardo, si può considerare che tutti i metodi del servizio Web restituiscono una struttura o una classe piccola che può contenere lo stato della chiamata , un codice di errore e un messaggio amichevole che potrebbe spiegare l'errore.

Answer 4

Sì, è necessario eseguire il wrapping della chiamata al servizio Web in try-catch. NON usare il pescato vuoto poiché (per lo più) sono puramente malvagi. Il blocco catch dovrebbe almeno registrare l'eccezione. Non conosco la logica delle tue applicazioni, ma probabilmente alcuni messaggi (come "le informazioni dal servizio non sono state recuperate a causa dell'errore tecnico") dovrebbero essere mostrate all'utente.

Answer 5

E 'ok, ma cercare di soli tipi di eccezione di cattura che è possibile gestire.

evitare la cattura qualsiasi "Eccezione" o, se lo fa, il login e/o avvisare l'utente e/o riprovare a chiamare il webservice.

Se si tratta di un'applicazione Windows Form di solito avvolgere l'ultima "Eccezione" catture in un blocco #if DEBUG per evitare che si nascondono eccezioni durante il debug o test.

#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(); 
      } 
     } 
     } 
} 

È una buona pratica o c'è spazio per miglioramenti?