lanciare o non generare l'eccezione dai metodi consumati dallo strato di ASP.NET Web API

Question

Si supponga che sto costruendo un'applicazione Web ASP.NET API ed ha la seguente struttura:

Come puoi vedere dal diagramma, il nucleo dell'API Web ASP.NET parlerà con il livello di servizio del dominio (ad esempio la classe MembershipService che ha metodi come GetUsers, CreateUser, ecc.) e le mie classi di servizio parleranno con uno o più repository per gestire il operazioni.

È ovvio che un'operazione di servizio (come il metodo MembershipService.CreateUser) non riuscirebbe per diversi motivi (condizioni non soddisfatte, un'eccezione generata dal repository, ecc.) E questo è il posto in cui ho dei dubbi.

Pensi che le classi di servizio dovrebbero gestire le eccezioni e restituire una sorta di oggetto risultato come il sotto di un:

public class OperationResult { 

    public OperationResult(bool isSuccess) : this(isSuccess) { 
     IsSuccess = isSuccess; 
    } 

    public OperationResult(bool isSuccess, Exception exception) : this(isSuccess) { 
     Exception = exception; 
    } 

    public bool IsSuccess { get; private set; } 
    public Exception IsSuccess { get; private set; } 
} 

public class OperationResult<TEntity> : OperationResult { 

    public OperationResult(bool isSuccess) 
     : base(isSuccess) { } 

    public OperationResult(bool isSuccess, Exception exception) 
     : base(isSuccess, exception) { } 

    public TEntity Entity { get; set; } 
} 

O pensi che i metodi di servizio non dovrebbe astratto l'eccezione del genere e dovrebbe lanciare l'eccezione direttamente o indirettamente (creando un nuovo tipo di eccezione significativo specifico per l'operazione e ponendo l'eccezione generata come sua eccezione interna)?

Answer 1

Quando si è in-process, utilizzare le eccezioni.

Answer 2

Prendendo una pagina dal libro di Microsoft, l'implementazione dell'API di appartenenza genera eccezioni anziché gestirle e restituire un oggetto risultato, quindi considererei questa una buona pratica purché non controlli sia il client che il API.

Nel caso in cui si controllano sia il client che l'API, è la mia preferenza personale per restituire un oggetto risultato o un messaggio di errore. Il motivo è che voglio registrare le informazioni dettagliate sull'origine delle eccezioni reali, ma non voglio un'eccezione per tutto ciò che potrebbe andare storto, come la password errata.

In questo caso, un semplice messaggio di errore per l'utente sarà più che sufficiente. Dall'esperienza del mondo reale, registrando eccezioni al registro eventi o al file di registro ogni volta che si verifica un errore di convalida è un grave onere per il personale operativo che sta tentando di determinare se si verifica un errore effettivo o se si tratta solo di un errore dell'utente .

Answer 3

Non vedo alcun punto per evitare eccezioni. Le eccezioni ci sono per buone ragioni, principalmente da usare! Basta provare a guardare l'immagine grande: si sta tentando di modificare il meccanismo di eccezione con il vecchio modo di controllare gli errori. In questo modo perderai tutti i meriti di Eccezioni (come la separazione della gestione degli errori e del codice normale, CallStack, ...) e non otterrai nulla in cambio.

Quello che faccio di solito in questa situazione è catturare l'eccezione nel livello di servizio e reinserirla in un'eccezione personalizzata (con il riferimento all'eccezione originale nel campo InnerException).