Bästa praxis vid hantering av undantag i C #

Undantagshantering är tekniken för hantering av runtime-fel i din applikationskod. I grund och botten har du två kategorier av undantag: Undantag som genereras av applikationen och de som genereras av körtiden. Undantag ska hanteras med försiktighet - du bör ha en god uppfattning om hur undantag ska hanteras och när de behövs för att hanteras i din kod. I det här inlägget kommer jag att presentera några tips och bästa metoder för att arbeta med undantag i C #.

Basklassen för alla undantag i .NET är Exception. Alla undantagsklasser i undantagshierarkin härrör direkt eller indirekt från denna klass. Klasserna ApplicationException och SystemException kommer från klassen Exception. Common Language Runtime (CLR) kastar en instans av en typ som härrör från SystemException när ett fel inträffar vid körning. Observera att du aldrig ska fånga SystemException eller kasta en instans av SystemException i programmets kod.

När du skapar anpassade undantagsklasser härleds alltid från klassen Undantag och inte från klassen ApplicationException. En av anledningarna till detta är att en instans av ApplicationException kastas av applikationen och aldrig av körtiden. När du kastar en instans av ApplicationException i din kod skulle du bara öka samtalsstacken utan att lägga till mycket värde.

Det är en dålig designmetod att använda undantagshantering för att returnera information från en metod. Om du returnerar undantagsdata från din metod är din klassdesign fel och bör ses över. Observera att undantag bubblas upp till högre nivå i metodanropshierarkin och det är inte bra att hantera undantag i alla lager i din applikation. Du bör hantera ett undantag så högt uppe i samtalshierarkin som möjligt - du kan konsumera ett undantag i presentationslagret och visa lämpliga meddelanden till användaren för att meddela det exakta felet som har inträffat.

Omkastning av ett undantag krävs när du vill återställa en databastransaktion. Det är en bra praxis att använda specifika undantag som FileNotFoundException, IOException, etc. när du skriver undantagshanterare och sedan ett allmänt fångstblock i slutet med Exception-klassen. Detta säkerställer att du lär känna det exakta felet eller det specifika felet som har inträffat. MSDN säger: "Klassen ApplicationException tillhandahåller inte information om orsaken till undantag. I de flesta scenarier bör inte fall av den här klassen kastas. I de fall där den här klassen omedelbart bör ett mänskligt läsbart meddelande som beskriver felet skickas till konstruktören. "

Du bör använda try-catch-block för att hantera undantag och använda ett slutligt block för att rensa upp de resurser som används i ditt program. Försöksblocket skulle innehålla kod som kan höja ett undantag, fångstblocket kommer att användas för att hantera undantaget som kastas inuti försöksblocket och slutligen kommer blocket att användas för att omplacera alla resurser som programmet har använt. Observera att det slutliga blocket garanteras att köras oavsett om ett undantag har inträffat eller inte. Därför är block äntligen det bästa stället i din kod för att städa upp de resurser som ditt program har använt.

Kodavsnittet nedan visar hur "användande" -uttrycket kan användas för att kassera resurser. Observera att "användande" -uttrycket motsvarar försök - slutligen blockera.

public string Read(string fileName)

{

try

{

string data;

using (StreamReader streamReader = new StreamReader(fileName))

{

data = streamReader.ReadToEnd();

}

return data;

}

catch (Exception)

{

throw;

}

}

Att kasta undantag är dyrt. Det är en dålig praxis att göra om undantag - vid omkastning av undantag skulle du förlora stackspåret.

try

{

//Some code that might throw an exception

}

catch(Exception ex)

{

throw ex;

}

Använd istället bara uttalandet "kasta" om du inte vill hantera undantaget i din undantagshanterare och sprida undantaget uppåt i samtalshierarkin.

try

{

//Some code that might throw an exception

}

catch(Exception ex)

{

throw;

}

Svälj aldrig undantag - du ska aldrig dölja det fel som har inträffat. Det är bra att logga undantag i din ansökan. När du loggar undantag bör du alltid logga undantagsinstansen så att hela stackspårningen loggas och inte endast undantagsmeddelandet. Här är ett exempel som illustrerar detta.

try

{

//Some code that might throw an exception

}

catch(Exception ex)

{

LogManager.Log(ex.ToString());

}

Du bör aldrig använda undantag för att sprida eller utföra affärsregler i din ansökan. Du kan undvika undantag i din kod genom att använda korrekt valideringslogik. Undantag bör i de flesta fall undvikas - du bör bara använda det när det behövs.

Du kan hänvisa till den här MSDN-artikeln för mer information.