ASP.NET MVC - Undantagshantering

När vi bygger en applikation med ASP.NET MVC och vi gör det med AJAX Vi måste vidta särskilda försiktighetsåtgärder när vi tittar på de fel som vårt program kan ge.
När en begäran misslyckas får vi en serverfel 500 vilket inte är bra för användaren att se eller kanske vi får ett meddelande med felspårningen från ASP.NET att om vi inte fångar det innan det kan ses utanför och en skadlig användare kan få data för att använda den och attackera vår webbplats.
För att undvika stora problem när vår applikation returnerar ett fel måste vi arbeta med att hantera dessa som undantag, så att innan felet uppstår kan vår applikation veta detta och skicka ett mer användarvänligt meddelande som inte äventyrar vår säkerhet.
A undantag uppstår när en del av vår kod försöker utföra en åtgärd och misslyckas, antingen försöker vi fråga om obefintlig data eller för att vi inte validerar vissa användardatainmatningar, om vi använder AJAX Vi kan få ett 500 -fel, men också om detta inte händer och felaktiga data kommer till vår handkontroll kan vi få ett felspår som det vi ser i följande bild:

De felspår De erbjuder sällan en användbar mängd information för utvecklaren och om vi inte städar vad det visar kan vi äventyra webbplatsens säkerhet genom att filtrera konfigurationsdata från vår applikation eller från vår server.
För att undvika alla problem som kan genereras när ett fel uppstår i ASP.NET vi kan hantera sådana fel som undantag och för detta kan vi fånga felet och skicka ett personligt meddelande eller helt enkelt skicka ett svar att sidan du letar efter inte finns.
Vad du ska användaFör att göra detta kan vi använda metoden HttpResponseException som gör att vi kan passera som parameter a HTTP -kod gillar 404 sidan hittades inte.
I följande bild ser vi en kod som använder den nämnda metoden för att hantera undantaget, låt oss se:

FÖRSTORA

Här är det som händer ganska enkelt, först söker vi efter elementet med id, om det returnerar tomt eller obefintligt, för vårt exempel validerar vi det med null, vi kommer att upprätta ett felmeddelande med metoden HttpResponseException vi ställer in en kod för ej hittad och förbereder ett anpassat meddelande, slutligen lanserar vi det meddelandet.
Tack vare detta vi undviker att skicka ett tomt eller tomt svar till vår ansökan vilket kunde ha orsakat att den gick sönder någon gång och visade ett felaktigt fel, skickade vi också ett vänligare meddelande till användaren om att deras fråga inte gav resultat.
Genom att få ett personligt meddelande kan vi också ge mer specifik information som en utvecklare kan använda, det är lättare att veta att produkten inte finns, än att behöva granska ett 100-raders spår för att ta reda på detsamma.
Vi avslutade handledningen efter att ha lärt oss lite mer om riskerna med att inte hantera fel, samt ha lärt oss hur man hanterar dem genom att behandla dem som undantag.