En webbapplikation kommer att ha många kvaliteter, men det finns en mörk sida som vi måste vara medvetna om och det är att den kommer att ha många fel, även om vi kan vidta alla försiktighetsåtgärder och göra alla enhetstester, kommer det alltid att finnas fall och situationer som vi inte såg. som kan explodera i en produktionsmiljö.
När ett dödligt fel utlöses är det sista vi vill att användaren ska se det felmeddelande det ger oss. ASP.NET MVC, det är därför vi måste lära oss att hantera misstag Y undantag så att vi kan vägleda vår applikation om hur man löser problemet.
Hantera ett fel i ASP.NET MVC
När vi arbetar med förfrågningar HTTP och med användarinmatning kan något gå fel och det är vårt jobb att försöka minimera detta, även om vi inte kommer att kunna alla fall, om vi kan skapa en komponent som på ett särskilt sätt tar upp de fel som vi inte känner till .
Ramverket tillåter oss att skapa anpassade felsidor om vi aktiverar motsvarande alternativ, alltså om ett fel uppstår eller undantag som vi inte hanterar kan vi visa en sida som är mindre dödlig än den klassiska ASP.NET MVC som vi kan se i följande bild:
Även om vi kan avfärda meddelandet finns det något oroande, om vi ser källkoden för var felet hände kan detta leda till säkerhetshål så det är viktigt att den här sidan aldrig syns i produktionen.
Anpassad felsida
Även om det inte är idealet att inte ha fel, men i sig är det en utopi, så vi måste leva med problemfrågan och att de alltid kommer att uppstå, i ASP.NET MVC vi kan ha tre sätt att hantera dessa.
De först är att alltid visa standardsidan som vi såg i den föregående bilden så när ett fel uppstår kommer vi att se den med alla risker som detta innebär. De andra status visar bara vår anpassade felsida, det hjälper oss att inte låta vår applikationskällkod visa.
Och slutligen tredje status och en av de mest användbara, att endast den anpassade felsidan syns när appen nås från en fjärradress, hjälper det här sista läget oss att felsöka eftersom om vi kör programmet och navigerar i det lokal värd vi kommer att se standardsidan för felen och därmed hjälper vi varandra med alla detaljer, men om det är en klient som ansluter från en annan maskin ser du bara det anpassade felet.
Använd tillståndFör att använda dessa tre stater behöver vi bara ändra direktivet customErrors, med värdena av, på och Endast Remote För var och en av de tillstånd som beskrivs ovan respektive kan vi placera den anpassade sidan för felen.
Låt oss se i följande bild en exempelkod på hur du justerar detta direktiv för konfigurationsfilen:
Vi ser att vi kan ställa in specifika sidor till kända fel som till exempel inte hittade eller 404, vi kan också göra det med 500 -felet och andra koder, med detta avslutar vi denna handledning som vi har lärt oss lite det grundläggande sättet att hantera fel i ASP.NET MVC.
Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng
