ASP.NET MVC - Undtagelseshåndtering

Når vi bygger en applikation med ASP.NET MVC og vi gør det ved hjælp af AJAX Vi skal tage særlige forholdsregler, når vi ser på de fejl, som vores program kan returnere.
Når en anmodning mislykkes, får vi en serverfejl 500 hvilket ikke er en god ting for brugeren at se, eller måske får vi en besked med fejlsporet fra ASP.NET at hvis vi ikke fanger det, før det kan ses udenfor, og en ondsindet bruger kan indhente data for at bruge det og angribe vores websted.
For at undgå større problemer, når vores applikation returnerer en fejl, skal vi arbejde med at håndtere disse som undtagelser, så før vores fejl opstår, kan vores applikation vide dette og sende en mere brugervenlig besked, der ikke går på kompromis med vores sikkerhed.
EN undtagelse opstår, når en del af vores kode forsøger at udføre en handling og mislykkes, enten prøver vi at forespørge om ikke-eksisterende data, eller fordi vi ikke validerer noget brugerdatainput, hvis vi bruger AJAX Vi får muligvis en 500 -fejl, men også hvis dette ikke sker, og der kommer en fejlagtig data til vores controller, kan vi få et fejlspor som det, vi ser i følgende billede:

Det fejlspor De tilbyder sjældent en nyttig mængde oplysninger til udvikleren, og hvis vi ikke renser, hvad det vil vise, kan vi kompromittere webstedets sikkerhed ved at filtrere konfigurationsdata fra vores applikation eller fra vores server.
For at undgå alle de problemer, der kan genereres, når der opstår en fejl i ASP.NET vi kan håndtere sådanne fejl som undtagelser og for dette kan vi fange fejlen og sende en personlig besked eller blot sende et svar om, at den side, du leder efter, ikke findes.
Hvad skal man brugeFor at gøre dette kan vi bruge metoden HttpResponseException der tillader os at passere som parameter a HTTP -kode like 404 side ikke fundet.
I det følgende billede ser vi en kode, der bruger den nævnte metode til at håndtere undtagelsen, lad os se:

FORSTØRRE

Her er det ganske enkelt, hvad der sker, først søger vi efter elementet ved hjælp af id'et, hvis det returnerer tomt eller ikke-eksisterende, for vores eksempel validerer vi det med null, vi vil etablere en fejlmeddelelse med metoden HttpResponseException vi angiver en kode for ikke fundet og forbereder en brugerdefineret besked, endelig starter vi den besked.
Takket være dette vi undgår at sende et nul eller tomt svar på vores ansøgning som kunne have fået den til at gå i stykker på et tidspunkt og vise en fejl forkert, sendte vi også en venligere besked til brugeren om, hvorfor deres forespørgsel ikke returnerede resultater.
Ved at få en personlig besked kan vi også give mere specifikke oplysninger, som en udvikler kan bruge, det er lettere at vide, at produktet ikke findes, end at skulle gennemgå et 100-linjespor for at finde ud af det samme.
Vi afsluttede selvstudiet efter at have lært lidt mere om risiciene ved ikke at håndtere fejl, samt have lært at håndtere dem ved at behandle dem som undtagelser.