I servizi Web generano eccezioni O oggetti risultato

Question

Non sono sicuro di essere completamente felice che gettare 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 al riguardo. CampaignMonitor ad esempio restituisce un oggetto Risultato, ma altri no.

Dal punto di vista architettonico, non sono sicuro che restituire un oggetto return 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?

Modifica

A proposito, sto usando i servizi web ASMX, dove l'attivazione di CustomErrors non è un'opzione.

Answer 1

Di quale traccia stack stai parlando? Hai provato questo?

In entrambi i servizi ASMX e WCF, un'eccezione non rilevata verrà tradotta 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 di restituire un errore come questo è attraverso un errore. Un modo per generare guasti è lanciare e non gestire un'eccezione.

Answer 2

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

Usa la tua normale strategia di gestione delle eccezioni. Le migliori pratiche indicano che non intercettare le eccezioni nel codice di basso livello, a meno che non sia possibile risolvere tale eccezione e continuare normalmente. Dovrebbero essere sollevate 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 si traduce in un SoapFault). Ciò consente al codice client che invoca di utilizzare lo standard di gestione delle eccezioni incorporato per gestirlo.

Answer 3

un approccio consiste nel separare gli errori di sistema e di business. (Errore di sistema: ad es. Richiesta non valida, utente non autorizzato, ecc .; errore commerciale: ad es. Metodo UpdateCars provoca un errore, l'utente non possiede alcuna macchina).

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

Answer 4

Puoi 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. Tale messaggio può contenere informazioni di errore e tali informazioni di errore possono includere specificamente i dettagli delle eccezioni. Oppure 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 sull'errore.

Quale parte di questo scenario ti stai chiedendo?

Answer 5

Suppongo che generare eccezioni sia in generale un modello di progettazione migliore che restituire un risultato. Suppongo che devi fare è all'interno dei tuoi servizi web per nascondere la traccia dello stack applicando il seguente modello a ciascun metodo esposto come servizio web:

  

public void MyWebServiceMethod ()   {
    provare
    {

 ///Do something that may cause an error

     

} catch (Eccezione ex)
     {         lancia nuova ApplicationException (" Facile da usare   descrizione dell'eccezione ");

     

}

     

}

oppure puoi anche

  

cattura (eccezione ex) {       buttare ex; }

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

Answer 6

Non vedo perché non puoi fare entrambe le cose? Catturare l'eccezione, registrarla (su un DB o su un file), quindi restituire un codice di errore. In questo modo hai un'esecuzione aggraziata della chiamata al servizio web, e anche la notifica dell'errore, e hai un posto altrove dove è possibile eseguire il debug.