Izņēmumu apstrāde ir izpildlaika kļūdu apstrādes tehnika jūsu lietojumprogrammas kodā. Būtībā jums ir divas izņēmumu kategorijas: izņēmumi, kurus ģenerē lietojumprogramma, un tie, kurus ģenerē izpildlaiks. Ar izņēmumiem jārīkojas piesardzīgi - jums vajadzētu labi izprast, kā rīkoties ar izņēmumiem un kad tie ir jārīkojas jūsu kodā. Šajā amatā es sniegšu dažus padomus un paraugpraksi darbam ar izņēmumiem C #.
Visu izņēmumu pamatklase .NET ir izņēmums. Visas izņēmumu klases izņēmumu hierarhijā tieši vai netieši izriet no šīs klases. Klase ApplicationException un SystemException ir atvasināta no klases Exception. Kopējās valodas izpildlaiks (CLR) izmet tāda veida gadījumu, kas atvasināts no SystemException, kad izpildlaika laikā rodas kļūda. Ņemiet vērā, ka jums nekad nevajadzētu noķert SystemException vai iemest SystemException gadījumu jūsu lietojumprogrammas kodā.
Veidojot pielāgotas izņēmumu klases, vienmēr iegūstiet klasi Izņēmums, nevis no klases ApplicationException. Viens no iemesliem ir tas, ka ApplicationException gadījumu izlaiž lietojumprogramma, nevis izpildlaiks. Iekļaujot kodā ApplicationException gadījumu, jūs vienkārši palielināsiet zvanu kaudzi, nepievienojot lielu vērtību.
Slikta dizaina pieeja ir izņēmumu apstrāde, lai atgrieztu informāciju no metodes. Ja atgriežat datus par izņēmumiem no savas metodes, jūsu klases dizains ir nepareizs, un tas ir jāpārskata. Ņemiet vērā, ka izņēmumi tiek burbuļoti līdz augstākajam metožu izsaukumu hierarhijas līmenim, un nav pareizi rīkoties ar izņēmumiem visos lietojumprogrammas slāņos. Jums vajadzētu rīkoties ar izņēmumu pēc iespējas augstāk zvanu hierarhijā - jūs varat patērēt izņēmumu prezentācijas slānī un parādīt lietotājam atbilstošus ziņojumus, lai paziņotu par precīzu radušos kļūdu.
Atkārtots izņēmums ir nepieciešams, ja vēlaties atcelt datu bāzes darījumu. Ir laba prakse izmantot īpašus izņēmumus, piemēram, FileNotFoundException, IOException utt., Rakstot izņēmumu apstrādātājus, un pēc tam vispārēju nozvejas bloku beigās ar izņēmuma klasi. Tas nodrošinātu, ka jūs uzzināt precīzu kļūdu vai konkrēto radušos kļūdu. MSDN norāda: "Klase ApplicationException nesniedz informāciju par izņēmumu cēloņiem. Lielākajā daļā gadījumu šīs klases gadījumus nevajadzētu mest. Gadījumos, kad šī klase ir instantificēta, ir jānosūta cilvēkiem lasāms ziņojums, kurā aprakstīta kļūda. nodots konstruktoram. "
Lai apstrādātu izņēmumus, jums jāizmanto izmēģinājuma ķeršanas bloki un jāizmanto pēdējais bloks, lai iztīrītu programmā izmantotos resursus. Mēģinājuma blokā būtu kods, kas varētu izraisīt izņēmumu, ķeršanas bloks tiks izmantots, lai apstrādātu mēģinājuma blokā izmesto izņēmumu, un pēdējais bloks tiks izmantots, lai sadalītu visus programmas izmantotos resursus. Ņemiet vērā, ka tiek garantēts, ka pēdējais bloks tiks izpildīts neatkarīgi no tā, vai ir noticis izņēmums. Tādējādi beidzot bloķēšana ir labākā vieta jūsu kodā, lai attīrītu jūsu izmantotos resursus.
Tālāk redzamais koda fragments parāda, kā "izmantojot" priekšrakstu var izmantot resursu iznīcināšanai. Ņemiet vērā, ka paziņojums "using" ir līdzvērtīgs try - beidzot bloķēšanai.
public string read (virknes faila nosaukums)
{
mēģiniet
{
virknes dati;
izmantojot (StreamReader streamReader = jauns StreamReader (fileName))
{
dati = streamReader.ReadToEnd ();
}
atgriešanās dati;
}
nozveja (izņēmums)
{
mest;
}
}
Izmest izņēmumus ir dārgi. Ir slikta prakse atkāpties no izņēmumiem - atkārtojot izņēmumus, jūs zaudētu kaudzes izsekošanu.
mēģiniet
{
// Daži kodi, kas varētu radīt izņēmumu
}
nozveja (izņēmums ex)
{
mest ex;
}
Tā vietā vienkārši izmantojiet paziņojumu "mest", ja nevēlaties rīkoties ar izņēmumu savā izņēmumu apstrādātājā un izsaukumu izsauciet uz augšu zvanu hierarhijā.
mēģiniet
{
// Daži kodi, kas var radīt izņēmumu
}
nozveja (izņēmums ex)
{
mest;
}
Nekad nenorijiet izņēmumus - nekad nevajadzētu slēpt radušos kļūdu. Tā ir laba prakse, lai pieteikumā reģistrētu izņēmumus. Reģistrējot izņēmumus, vienmēr jāpierakstās izņēmuma gadījums, lai tiktu reģistrēta visa kaudzes izsekošana, nevis tikai izņēmuma ziņojums. Šeit ir piemērs, kas to ilustrē.
mēģiniet
{
// Daži kodi, kas varētu radīt izņēmumu
}
nozveja (izņēmums ex)
{
LogManager.Log (piem. ToString ());
}
Nekad nevajadzētu izmantot izņēmumus, lai izplatītu vai izpildītu biznesa kārtulas savā lietojumprogrammā. Izmantojot pareizu validācijas loģiku, varat izvairīties no izņēmumiem savā kodā. Vairumā gadījumu ir jāizvairās no izņēmumiem - tas jālieto tikai tad, kad tas ir nepieciešams.
Lai iegūtu papildinformāciju, varat atsaukties uz šo MSDN rakstu.
