Programiranje

Najboljše prakse pri ravnanju z izjemami v jeziku C #

Obravnava izjem je tehnika obdelave napak med izvajanjem v kodi aplikacije. V bistvu imate dve kategoriji izjem: izjeme, ki jih ustvari aplikacija, in tiste, ki jih ustvari izvajalno okolje. Z izjemami je treba ravnati previdno - dobro morate vedeti, kako je treba ravnati z izjemami in kdaj jih je treba obravnavati v vaši kodi. V tej objavi bom predstavil nekaj nasvetov in najboljših praks za delo z izjemami v C #.

Osnovni razred za vse izjeme v .NET je Exception. Vsi razredi izjem v hierarhiji izjem izhajajo neposredno ali posredno iz tega razreda. Razreda ApplicationException in SystemException izhajata iz razreda Exception. CLR (Common Language Runtime) vrže primerek tipa, ki je izpeljan iz SystemException, ko pride do napake med izvajanjem. Upoštevajte, da nikoli ne smete ujeti SystemException ali metati primerka SystemException v kodo aplikacije.

Ko ustvarjate razrede izjem po meri, vedno izvirajte iz razreda Exception in ne iz razreda ApplicationException. Eden od razlogov za to je, da primerek ApplicationException odda aplikacija in nikoli izvajalno okolje. Če v svojo kodo vržete primerek ApplicationException, bi samo povečali kup klicev, ne da bi dodali veliko vrednost.

Slab oblikovalski pristop je, da se za vrnitev informacij iz metode uporablja obdelava izjem. Če iz metode vračate podatke o izjemah, je zasnova vašega razreda napačna in jo je treba ponovno obiskati. Upoštevajte, da so izjeme v hierarhiji klicev metode v mehurčkih na višjo raven, zato ni dobro ravnati z izjemami v vseh slojih aplikacije. Izjemo bi morali obravnavati čim višje v hierarhiji klicev - izjemo lahko uporabite v predstavitveni plasti in uporabniku prikažete ustrezna sporočila, da obvestijo o natančni napaki, ki se je zgodila.

Če želite vrniti transakcijo baze podatkov, je potrebna ponovna meta izjeme. Dobra praksa je, da pri zapisovanju obdelovalcev izjem uporabljate posebne izjeme, kot so FileNotFoundException, IOException itd., Nato pa na koncu splošni ulovni blok z razredom Exception. To bi zagotovilo, da boste natančno spoznali napako ali določeno napako, ki se je zgodila. MSDN pravi: "Razred ApplicationException ne vsebuje informacij o vzrokih izjem. V večini primerov primerki tega razreda ne bi smeli biti zavrženi. posredovano konstruktorju. "

Za obdelavo izjem uporabite bloke try - catch in za čiščenje virov, uporabljenih v programu, uporabite block. Blok poskus bi vseboval kodo, ki bi lahko povzročila izjemo, blok catch bo uporabljen za obdelavo izjeme, vržene znotraj bloka try, končni blok pa bo uporabljen za sprostitev vseh virov, ki jih je program uporabil. Upoštevajte, da je zaključni blok zagotovljeno izveden ne glede na to, ali je prišlo do izjeme ali ne. Zato je na koncu blok najboljše mesto v kodi za čiščenje virov, ki jih je uporabil vaš program.

Spodnji delček kode prikazuje, kako se lahko stavk "using" uporablja za odstranjevanje virov. Upoštevajte, da je izjava "using" enakovredna poskusu - na koncu blokirajte.

javni niz Read (string fileName)

{

poskusite

{

niz podatkov;

z uporabo (StreamReader streamReader = new StreamReader (fileName))

{

data = streamReader.ReadToEnd ();

}

vrniti podatke;

}

ulov (izjema)

{

metati;

}

}

Metanje izjem je drago. Slaba praksa je vračanje izjem - pri ponovnem vračanju izjem bi izgubili sled sklada.

poskusite

{

// Neka koda, ki bi lahko povzročila izjemo

}

ulov (izjema ex)

{

metati ex;

}

Namesto tega uporabite stavek "throw", če ne želite obdelovati izjeme v svojem obdelovalcu izjem in razširite izjemo navzgor v hierarhiji klicev.

poskusite

{

// Nekaj ​​kode, ki bi lahko povzročila izjemo

}

ulov (izjema ex)

{

metati;

}

Nikoli ne pogoltnite izjem - nikoli ne smete skrivati ​​napake, ki se je zgodila. Dobra praksa je, da v svojo prijavo beležite izjeme. Ko beležite izjeme, morate vedno zapisovati primerek izjeme, tako da se zabeleži celotna sled skladbe, ne pa samo sporočilo o izjemi. Tu je primer, ki to ponazarja.

poskusite

{

// Neka koda, ki bi lahko povzročila izjemo

}

ulov (izjema ex)

{

LogManager.Log (ex.ToString ());

}

Nikoli ne bi smeli uporabljati izjem za razširjanje ali izvajanje poslovnih pravil v svoji aplikaciji. Izjemam v kodi se lahko izognete z uporabo ustrezne logike preverjanja. V večini primerov se je treba izogibati izjemam - uporabljajte jih le, kadar je to potrebno.

Za več informacij se lahko obrnete na ta članek MSDN.

$config[zx-auto] not found$config[zx-overlay] not found