ASP.NET MVC - Gestione delle eccezioni

Quando creiamo un'applicazione con ASP.NET MVC e lo stiamo facendo usando AJAX Dobbiamo prendere precauzioni speciali quando esaminiamo gli errori che il nostro programma può restituire.
Quando una richiesta fallisce, otterremo un errore del server 500 che non è una buona cosa per l'utente da vedere o forse riceviamo un messaggio con la traccia dell'errore da ASP.NET che se non lo catturiamo prima che possa essere visto all'esterno e un utente malintenzionato potrebbe ottenere dati per utilizzarlo e attaccare il nostro sito.
Per evitare grossi problemi quando la nostra applicazione restituisce un errore, dobbiamo lavorare per gestirli come eccezioni, in modo che prima che si verifichi l'errore, la nostra applicazione possa saperlo e lanciare un messaggio più intuitivo che non comprometta la nostra sicurezza.
UN eccezione si verifica quando una parte del nostro codice tenta di eseguire un'azione e fallisce, tentando di interrogare dati inesistenti o perché non convalidiamo alcuni input di dati dell'utente, se stiamo utilizzando AJAX Potremmo ottenere un errore 500, ma anche se ciò non accade e arriva un dato errato al nostro controller, potremmo ottenere una traccia di errore come quella che vediamo nell'immagine seguente:

Il tracce di errore Raramente offrono una quantità di informazioni utili per lo sviluppatore e se non puliamo ciò che mostrerà possiamo compromettere la sicurezza del sito filtrando i dati di configurazione dalla nostra applicazione o dal nostro server.
Per evitare tutti i problemi che si possono generare quando si verifica un errore in ASP.NET possiamo gestire errori come eccezioni e per questo possiamo catturare l'errore e inviare un messaggio personalizzato o semplicemente inviare una risposta che la pagina che stai cercando non esiste.
Cosa usare?Per fare questo possiamo usare il metodo HttpResponseException che ci permette di passare come parametro a Codice HTTP come 404 pagina non trovata.
Nell'immagine seguente vediamo un codice che utilizza il metodo citato per gestire l'eccezione, vediamo:

INGRANDIRE

Qui quello che succede è abbastanza semplice, prima cerchiamo l'elemento in base all'id, nel caso in cui restituisca vuoto o inesistente, per il nostro esempio lo convalidiamo con null, stabiliamo un messaggio di errore, con il metodo HttpResponseException impostiamo un codice di non trovato e prepariamo un messaggio personalizzato, infine lanciamo quel messaggio.
Grazie a questo evitiamo di inviare una risposta nulla o vuota alla nostra applicazione che avrebbe potuto causare la rottura ad un certo punto e visualizzare un errore in modo errato, abbiamo anche inviato un messaggio più amichevole all'utente indicando il motivo per cui la sua query non ha restituito risultati.
Ottenendo un messaggio personalizzato possiamo anche dare informazioni più specifiche che uno sviluppatore può utilizzare, è più facile sapere che il prodotto non esiste, che dover rivedere una traccia di 100 righe per scoprirlo.
Abbiamo terminato il tutorial dopo aver appreso qualcosa in più sui rischi di non gestire gli errori, oltre ad aver imparato a gestirli trattandoli come eccezioni.