Zpracování výjimek je technika zpracování chyb za běhu v kódu aplikace. V zásadě máte dvě kategorie výjimek: Výjimky generované aplikací a ty, které jsou generovány modulem runtime. S výjimkami je třeba zacházet opatrně - měli byste mít dobrou představu o tom, jak by měly být výjimky zpracovány a kdy je třeba je v kódu zpracovat. V tomto příspěvku představím několik tipů a osvědčených postupů pro práci s výjimkami v C #.
Základní třída pro všechny výjimky v .NET je výjimka. Všechny třídy výjimek v hierarchii výjimek jsou odvozeny přímo nebo nepřímo z této třídy. Třídy ApplicationException a SystemException jsou odvozeny od třídy Exception. Common Language Runtime (CLR) vyvolá instanci typu, který je odvozen od SystemException, když dojde k chybě za běhu. Všimněte si, že byste nikdy neměli chytit SystemException nebo hodit instanci SystemException do kódu vaší aplikace.
Při vytváření vlastních tříd výjimek se vždy odvozuje od třídy Exception a nikoli od třídy ApplicationException. Jedním z důvodů je to, že instance ApplicationException je vyvolána aplikací a nikdy modulem runtime. Při vyvolání instance ApplicationException ve vašem kódu byste jen zvětšili zásobník volání bez přidání větší hodnoty.
Jde o špatný návrhový přístup k použití zpracování výjimek k vrácení informací z metody. Pokud vracíte data výjimky z vaší metody, je váš návrh třídy špatný a měl by být znovu navštíven. Všimněte si, že výjimky jsou probublávány na vyšší úroveň v hierarchii volání metod a není dobrým zvykem zpracovávat výjimky ve všech vrstvách vaší aplikace. Výjimku v hierarchii volání byste měli zpracovávat co nejvíc - můžete využít výjimku v prezentační vrstvě a zobrazit příslušné zprávy uživateli, aby upozornily na přesnou chybu, ke které došlo.
Opětovné vyvolání výjimky je nutné, pokud chcete vrátit transakci databáze zpět. Je dobrým zvykem používat při psaní obslužných rutin výjimek specifické výjimky, jako je FileNotFoundException, IOException atd., A poté obecný blok úlovků na konci třídy Exception. Tím by bylo zajištěno, že poznáte přesnou chybu nebo konkrétní chybu, ke které došlo. MSDN uvádí: "Třída ApplicationException neposkytuje informace o příčinách výjimek. Ve většině scénářů by instance této třídy neměly být vyvolány. V případech, kdy je tato třída vytvořena, by měla být čitelná zpráva popisující chybu předán konstruktérovi. “
Měli byste použít bloky try - catch ke zpracování výjimek a použít blok finally k vyčištění prostředků použitých ve vašem programu. Blok try by obsahoval kód, který by mohl vyvolat výjimku, blok catch se použije ke zpracování výjimky vyvolané uvnitř bloku try a blok final se použije k uvolnění prostředků, které program použil. Všimněte si, že je zaručeno, že bude konečný blok proveden bez ohledu na to, zda došlo k výjimce nebo ne. Blok je tedy nejlepší místo ve vašem kódu pro vyčištění prostředků, které váš program použil.
Fragment kódu níže ukazuje, jak lze příkaz „using“ použít k vyřazení zdrojů. Všimněte si, že příkaz „using“ je ekvivalentem bloku try - finally.
veřejné čtení řetězce (řetězec název_souboru)
{
Snaž se
{
data řetězce;
pomocí (StreamReader streamReader = nový StreamReader (název souboru))
{
data = streamReader.ReadToEnd ();
}
vrátit data;
}
úlovek (výjimka)
{
házet;
}
}
Házení výjimek je drahé. Je špatnou praxí znovu generovat výjimky - při opětovném generování výjimek byste ztratili trasování zásobníku.
Snaž se
{
// Nějaký kód, který by mohl vyvolat výjimku
}
úlovek (výjimka mimo)
{
hodit ex;
}
Místo toho použijte příkaz „hodit“, pokud si nepřejete zpracovat výjimku v obslužné rutině výjimky a šířit výjimku nahoru v hierarchii volání.
Snaž se
{
// Nějaký kód, který by mohl vyvolat výjimku
}
úlovek (výjimka mimo)
{
házet;
}
Nikdy nepřehýbejte výjimky - nikdy byste neměli skrýt chybu, ke které došlo. Je dobrým zvykem protokolovat výjimky do vaší aplikace. Při protokolování výjimek byste měli vždy zaznamenat instanci výjimky, aby se protokolovalo úplné trasování zásobníku, a nikoli pouze zpráva o výjimce. Zde je příklad, který to ilustruje.
Snaž se
{
// Nějaký kód, který by mohl vyvolat výjimku
}
úlovek (výjimka mimo)
{
LogManager.Log (ex.ToString ());
}
Nikdy byste neměli používat výjimky k šíření nebo provádění obchodních pravidel ve vaší aplikaci. Můžete se vyhnout výjimkám v kódu pomocí správné logiky ověření. Ve většině případů byste se měli vyvarovat výjimek - měli byste je používat pouze v případě potřeby.
Další informace najdete v tomto článku MSDN.
