Gestione delle eccezioni in ASP.NET Web Api 2

Question

Problema:

ho bisogno di gestire API Web 2 eccezioni e restituire un oggetto ricco con il codice di stato corretto (401 per non autorizzato, 404 per ContentNotFound, etc) e alcune informazioni extra come il contenuto. Inoltre, ho bisogno che il contenuto assomigli ad un oggetto serializzato Exception (avere le proprietà message, exceptionMessage, stackTrace, ...).

soluzioni suggerite:

1. creare classi di eccezioni personalizzate e la scrittura di un filtro di eccezione personalizzato da applicare all'azione qualsiasi del controller. questo filtri eccezione personalizzata gestisce l'eccezione generata in base al suo tipo (una delle eccezioni personalizzate che ho già definito) e risponde di conseguenza via qualcosa come questo (il codice del filtro):

   context.Response = context.Request.CreateErrorResponse(HttpStatusCode.Unauthorized, 
               new Exception("my exception"))); 
   

2. avvolgendo il web già scritto api 2 *ActionResult classi (System.Web.Http.Results.UnauthorizedResult Unauthorized(), System.Web.Http.Results.OkResult Ok(), ecc.) e aggiungono alcuni dati personalizzati a loro e li usano in modo che i loro risultati vengano passati al client ogni volta che vengono chiamati (il problema è in questo caso il tipo di ritorno dell'azione del mio controller dovrebbe essere IHttpActionResult che non è così facilmente testabile e leggibile come un'azione fortemente tipizzata).

Quale soluzione dovrei scegliere? O c'è un altro modo per fare ciò che sto cercando di ottenere qui?

Answer 1

Oppure è possibile utilizzare la soluzione integrata pronta per l'uso: exception filters.

Inoltre, potresti essere interessato a exception handling starting from Web API 2.x.

Answer 2

Da quello che ho capito, non si desidera gestire le eccezioni generate dal codice, ma piuttosto crearle nei metodi di azione. Nel caso in cui le eccezioni vengono lanciate da altre aree nel codice (altre cose chiamate all'interno delle azioni o da altri filtri, è possibile utilizzare i filtri delle eccezioni o la gestione globale degli errori).

Quindi vorrei andare con il vostro secondo approccio (anche se non è necessario personalizzare i risultati dell'azione molto). Il tuo codice è in realtà molto più facile da testare con IHttpActionResult, perché puoi controllare direttamente il tipo di risultato. Infatti uno dei motivi per cui IHttpActionResults è stato aggiunto è quello di semplificare il testing delle unità.

Il flusso del codice è più semplice in quanto non è necessario lanciare per generare errori e si può sempre ispezionare il contenuto di un ok (returnValue) come si può vedere di seguito.

[TestMethod] 
public void GetProduct_ShouldReturnCorrectProduct() 
{ 
    var testProducts = GetTestProducts(); 
    var controller = new SimpleProductController(testProducts); 

    var result = controller.GetProduct(4) as OkNegotiatedContentResult<Product>; 
    Assert.IsNotNull(result); 
    Assert.AreEqual(testProducts[3].Name, result.Content.Name); 
} 

http://www.asp.net/web-api/overview/testing-and-debugging/unit-testing-with-aspnet-web-api