Se i servizi web generano eccezioni O oggetti risultato

Question

Non sono sicuro di essere completamente soddisfatto del fatto che il lancio di eccezioni nei servizi Web sia una buona idea. Non mi dispiacerebbe tanto se non fosse per la traccia dello stack. Questo non è qualcosa che non voglio.

Ho studiato diverse implementazioni e non sembra esserci un consenso su questo. Ad esempio, CampaignMonitor restituisce un oggetto Result, mentre altri no.

Architettonicamente, non sono sicuro che restituire un oggetto di ritorno abbia senso, sicuramente un'eccezione è un'eccezione, ma quello che mi piace di un oggetto Return è che è una soluzione più elegante per l'utente finale.

Qualcuno ha soluzioni migliori?

EDIT

BTW sto usando i servizi web ASMX, dove girando CustomErrors su non è un'opzione.

Answer 1

Quale traccia di stack stai parlando? Hai provato questo?

In entrambi i servizi ASMX e WCF, un'eccezione non rilevata verrà convertita in un errore SOAP. In entrambi i casi, possono essere configurati per non includere alcuna traccia dello stack. In realtà, questo è il valore predefinito in WCF.

Quindi, il modo corretto per restituire un errore di questo tipo è un errore. Un modo per generare errori consiste nel lanciare e non gestire un'eccezione.

Answer 2

Potete chiarire un po '? Il lato server di un servizio Web può generare un'eccezione. Il lato server di un servizio Web può restituire un messaggio al lato client. Questo messaggio può contenere informazioni di errore e tali informazioni di errore possono includere in modo specifico i dettagli delle eccezioni. O forse no. Sul lato client, in genere si dispone di un proxy generato per gestire il messaggio dal server. Questo proxy può generare un'eccezione se tale risposta contiene informazioni di errore.

Quale parte di questo scenario ti stai chiedendo?

Answer 3

Suppongo che il lancio di eccezioni sia in generale un modello di progettazione migliore che restituisca un risultato. Suppongo che si deve fare è dentro i vostri servizi web per nascondere traccia dello stack applicando il seguente schema per ogni metodo esposto come servizio Web:

public void MyWebServiceMethod() {
try
{

///Do something that may cause an error 

} catch(Exception ex)
{ throw new ApplicationException("User friendly descritption of exception");

}

}

oppure si può anche

catch(Exception ex) { throw ex; }

Se Rilanciare un'eccezione, nasconderai la traccia dello stack originale dai client dei tuoi servizi web.

Answer 4

Non lasciare che il fatto di essere in un servizio Web confonda il problema. Questo è solo un dettaglio di implementazione.

Utilizzare la normale strategia di gestione delle eccezioni. Le migliori pratiche dicono che non intercettano le eccezioni nel codice di basso livello, a meno che tu non possa risolvere quell'eccezione e continuare normalmente. È necessario aumentare le eccezioni al livello di presentazione in modo che l'utente possa essere informato dell'errore.

Quindi, come applicato ai servizi Web - in generale genera eccezioni (che risulta in un SoapFault). Ciò consente al codice client di richiamo di utilizzare lo standard di gestione delle eccezioni incorporato per gestirlo.

Answer 5

un approccio è quello di separare gli errori di sistema e di business. (Errore di sistema: ad esempio richiesta errata, utente non autorizzato, ecc., Errore di business: ad esempio, il metodo UpdateCars genera un errore, l'utente non possiede alcuna macchina).

In caso di un errore aziendale, restituire un oggetto risposta contenente una descrizione dell'errore; in caso di errore di sistema, lanciare un'eccezione.

Answer 6

Non vedo perché non puoi fare entrambe le cose? Catch l'eccezione, registrarlo (su un DB o su un file), quindi restituire un codice di errore. In questo modo si esegue in modo aggraziato la chiamata al servizio web e si notifica anche l'errore, e si dispone di un punto altrove è possibile eseguire ulteriori debug.