Undtagelseshåndtering er teknikken til håndtering af kørselsfejl i din applikationskode. Dybest set har du to kategorier af undtagelser: Undtagelser, der genereres af applikationen, og dem, der genereres af runtime. Undtagelser skal håndteres med forsigtighed - du skal have en god idé om, hvordan undtagelser skal håndteres, og hvornår de skal håndteres i din kode. I dette indlæg vil jeg præsentere et par tip og bedste praksis til at arbejde med undtagelser i C #.
Baseklassen for alle undtagelser i .NET er Undtagelse. Alle undtagelsesklasser i undtagelseshierarkiet stammer direkte eller indirekte fra denne klasse. Klasserne ApplicationException og SystemException stammer fra klassen Exception. Common Language Runtime (CLR) kaster en forekomst af en type, der er afledt af SystemException, når der opstår en fejl ved kørsel. Bemærk, at du aldrig skal fange SystemException eller kaste en forekomst af SystemException i din applikations kode.
Når du opretter tilpassede undtagelsesklasser, skal du altid stamme fra klassen Undtagelse og ikke fra klassen ApplicationException. En af grundene til dette er, at en forekomst af ApplicationException kastes af applikationen og aldrig af runtime. Når du smider en forekomst af ApplicationException i din kode, vil du bare øge opkaldstakken uden at tilføje meget værdi.
Det er en dårlig designtilgang at bruge undtagelseshåndtering til at returnere information fra en metode. Hvis du returnerer undtagelsesdata fra din metode, er dit klassedesign forkert og bør revurderes. Bemærk, at undtagelser bobles op til det højere niveau i metodeopkaldshierarkiet, og det er ikke en god praksis at håndtere undtagelser i alle lagene i din applikation. Du skal håndtere en undtagelse så højere op i opkaldshierarkiet, som du kan - du kan forbruge en undtagelse i præsentationslaget og vise passende meddelelser til brugeren for at meddele den nøjagtige fejl, der er opstået.
Det er nødvendigt at genkaste en undtagelse, når du gerne vil tilbageføre en databasetransaktion. Det er en god praksis at bruge specifikke undtagelser som FileNotFoundException, IOException osv., Når du skriver undtagelsesbehandlere og derefter en generel fangstblok i slutningen med Exception-klassen. Dette vil sikre, at du lærer den nøjagtige fejl eller den specifikke fejl, der er opstået. MSDN siger: "ApplicationException-klassen giver ikke information om årsagen til undtagelser. I de fleste scenarier bør forekomster af denne klasse ikke kastes. I de tilfælde, hvor denne klasse er instanseret, skal der læses en menneskelig læsbar besked, der beskriver fejlen. videregivet til konstruktøren. "
Du skal bruge try-catch-blokke til at håndtere undtagelser og bruge en endelig blok til at rydde op i de ressourcer, der bruges i dit program. Prøveblokken vil indeholde kode, der muligvis hæver en undtagelse, fangstblokken bruges til at håndtere den undtagelse, der kastes inde i prøveblokken, og den endelige blok bruges til at omfordele de ressourcer, programmet har brugt. Bemærk, at den endelige blok garanteres at blive udført, uanset om der er sket en undtagelse eller ej. Derfor er endelig blok det bedste sted i din kode til at rydde op i de ressourcer, dit program har brugt.
Kodestykket nedenfor viser, hvordan "brug" -sætningen kan bruges til at bortskaffe ressourcer. Bemærk, at "brug" -sætningen svarer til prøve - til sidst blok.
offentlig streng Læs (streng filnavn)
{
prøve
{
streng data;
ved hjælp af (StreamReader streamReader = ny StreamReader (filnavn))
{
data = streamReader.ReadToEnd ();
}
returnere data
}
fangst (undtagelse)
{
kaste;
}
}
At kaste undtagelser er dyrt. Det er en dårlig praksis at omlægge undtagelser - ved omkastning af undtagelser mister du staksporet.
prøve
{
// Noget kode, der muligvis kaster en undtagelse
}
fangst (undtagelse ex)
{
smide ex;
}
Brug i stedet bare udsagnet "kast", hvis du ikke vil håndtere undtagelsen i din undtagelsesbehandler og udbrede undtagelsen opad i opkaldshierarkiet.
prøve
{
// Noget kode, der muligvis kaster en undtagelse
}
fangst (undtagelse ex)
{
kaste;
}
Slug aldrig undtagelser - du skal aldrig skjule den fejl, der er opstået. Det er en god praksis at logge undtagelser i din ansøgning. Når du logger undtagelser, skal du altid logge undtagelsesforekomsten, så den komplette stakksporing er logget og ikke kun undtagelsesmeddelelsen. Her er et eksempel, der illustrerer dette.
prøve
{
// Noget kode, der muligvis kaster en undtagelse
}
fangst (undtagelse ex)
{
LogManager.Log (ex.ToString ());
}
Du bør aldrig bruge undtagelser til at udbrede eller udføre forretningsregler i din applikation. Du kan undgå undtagelser i din kode ved at bruge korrekt valideringslogik. Undtagelser bør i de fleste tilfælde undgås - du bør kun bruge det, når det er nødvendigt.
Du kan henvise til denne MSDN-artikel for mere information.
