Poikkeusten käsittely on tekniikka, jolla käsitellään ajonaikaisia virheitä sovelluskoodissasi. Periaatteessa sinulla on kaksi poikkeusluokkaa: Sovelluksen luomat poikkeukset ja ajon aikana syntyvät poikkeukset. Poikkeuksia tulee käsitellä varoen - sinulla tulisi olla hyvä käsitys siitä, miten poikkeuksia tulisi käsitellä ja milloin niitä on käsiteltävä koodissasi. Tässä viestissä esitän muutamia vinkkejä ja parhaita käytäntöjä poikkeusten käsittelemiseksi C #: ssä.
Kaikkien .NET: n poikkeusten perusluokka on poikkeus. Kaikki poikkeushierarkian poikkeusluokat ovat suoraan tai epäsuorasti peräisin tästä luokasta. ApplicationException- ja SystemException-luokat ovat peräisin Exception-luokasta. Common Language Runtime (CLR) heittää tyypin, joka on johdettu SystemExceptionista, esiintymisen, kun ajon aikana ilmenee virhe. Huomaa, että sinun ei pitäisi koskaan tarttua SystemExceptioniin tai heittää SystemExceptionin esiintymää sovelluksesi koodiin.
Luotaessa mukautettuja poikkeusluokkia, tule aina Exception-luokasta eikä ApplicationException-luokasta. Yksi syy tähän on, että ApplicationException-ilmentymä heitetään sovelluksen eikä koskaan ajon aikana. Heittäessäsi koodiin ApplicationException-ilmentymän, vain lisäisit puhelupinoa lisäämättä paljon arvoa.
On huono suunnittelutapa käyttää poikkeusten käsittelyä tietojen palauttamiseksi menetelmästä. Jos palautat poikkeustietoja menetelmästäsi, luokkasi suunnittelu on väärä ja se tulisi tarkistaa. Huomaa, että poikkeukset on kuplittu metodikutsuhierarkian ylemmälle tasolle, eikä ole hyvä käytäntö käsitellä poikkeuksia sovelluksen kaikissa tasoissa. Sinun tulisi käsitellä poikkeusta niin korkealla puheluhierarkiassa kuin mahdollista - voit käyttää poikkeusta esityskerroksessa ja näyttää asianmukaiset viestit käyttäjälle ilmoittamaan tapahtuneesta virheestä.
Poikkeus on tehtävä uudelleen, kun haluat palauttaa tietokantatapahtuman. Hyvä käytäntö on käyttää erityisiä poikkeuksia, kuten FileNotFoundException, IOException jne., Kirjoitettaessa poikkeuskäsittelijöitä ja sitten yleistä salauslohkoa Exception-luokan lopussa. Tämä varmistaa, että opit tarkan virheen tai tapahtuneen virheen. MSDN toteaa: "ApplicationException-luokka ei tarjoa tietoja poikkeusten syistä. Useimmissa tilanteissa tämän luokan esiintymiä ei pidä heittää. Tapauksissa, joissa tämä luokka on instansoitu, virheen kuvaava ihmislukuinen viesti siirretty rakentajalle. "
Sinun tulisi käyttää try-catch-lohkoja poikkeusten käsittelemiseen ja käyttää viimeistä lohkoa siivoamaan ohjelmassa käytetyt resurssit. Kokeilulohko sisältäisi koodin, joka saattaisi aiheuttaa poikkeuksen, lukituslohkoa käytetään kokeilulohkon sisään heitetyn poikkeuksen käsittelemiseen ja viimeistä lohkoa käytetään ohjelman käyttämien resurssien jakamiseen. Huomaa, että viimeinen lohko toteutetaan taatusti riippumatta siitä, onko poikkeus tapahtunut vai ei. Siksi lopuksi lohko on paras paikka koodissasi ohjelman käyttämiesi resurssien puhdistamiseen.
Alla oleva koodinpätkä osoittaa, kuinka "using" -käskyä voidaan käyttää resurssien hävittämiseen. Huomaa, että "using" -lauseke vastaa try - lopulta estoa.
public string Read (merkkijonon tiedostonimi)
{
yrittää
{
merkkijonodata;
käyttäen (StreamReader streamReader = uusi StreamReader (tiedostonimi))
{
data = streamReader.ReadToEnd ();
}
palautustiedot;
}
saalis (poikkeus)
{
heittää;
}
}
Poikkeusten heittäminen on kallista. On huono käytäntö hakea uudelleen poikkeuksia - uudelleenkirjoittamalla poikkeuksia menettäisit pinon jäljet.
yrittää
{
// Jotkut koodit, jotka saattavat aiheuttaa poikkeuksen
}
saalis (poikkeus ex)
{
heittää ex;
}
Käytä sen sijaan vain lausetta "heittää", jos et halua käsitellä poikkeusta poikkeuskäsittelijässäsi ja levitä poikkeusta ylöspäin puheluhierarkiassa.
yrittää
{
// Jotkut koodit, jotka saattavat aiheuttaa poikkeuksen
}
saalis (poikkeus ex)
{
heittää;
}
Älä koskaan niele poikkeuksia - sinun ei pitäisi koskaan piilottaa tapahtunutta virhettä. On hyvä käytäntö kirjata poikkeukset sovellukseesi. Kun kirjaat poikkeuksia, sinun tulee aina kirjata poikkeusilmentymä siten, että koko pinon jäljitys kirjataan eikä vain poikkeussanoma. Tässä on esimerkki, joka kuvaa tätä.
yrittää
{
// Jotkut koodit, jotka saattavat aiheuttaa poikkeuksen
}
saalis (poikkeus ex)
{
LogManager.Log (esim.ToString ());
}
Älä koskaan käytä poikkeuksia liiketoimintasääntöjen levittämiseen tai toteuttamiseen sovelluksessasi. Voit välttää poikkeuksia koodissasi käyttämällä oikeaa vahvistuslogiikkaa. Poikkeuksia tulisi useimmissa tapauksissa välttää - sinun tulisi käyttää sitä vain silloin, kun sitä tarvitaan.
Voit lukea lisätietoja tästä MSDN-artikkelista.
