Times like these

Virheenkäsittely Javassa

Kesäkuu 29th, 2006

Javassa on varsin mainio tuki virheenkäsittelylle. Ikävä kyllä monesti näkee, että virheenkäsittelyä on yritetty keksiä uudestaan tai sen perusperiaatteita ei ole yksinkertaisesti ymmärretty laisinkaan.

Tässä joitain perussääntöjä:

1. Jos koodi ei tule JVM:ään tai johonkin muuhun säiliöön, ei ole mitään järkevää syytä koskaan ottaa kiinni Throwablea. Tarkemmin sanottuna se johtaa helposti aika pahoihin vaikeuksiin. Jos jotain fataalia tosiaan tapahtuu JVM:n puolella (esim. muisti loppuu), kannattaa se yleensä jättää JVM:n hoidettavaksi.
2. RunTimeExceptioneita käytetään ainoastaan, jos virheet ovat sellaisia, ettei niitä ole tarkoitus sovelluskoodissa ottaa kiinni. RunTimeException viittaa useimmiten ohjelmointivirheeseen, kuten esimerkiksi NullPointerException ja ClassCastException.
3. Yllä mainitusta syystä ei myöskään ole järkevää napata kiinni Exception-instansseja, niihin kun tippuvat kaikki RunTimeExceptionitkin.
4. Edelleen samasta syystä, “throws Exception” metodissa on käytännössä aina ohjelmointivirhe.
5. Metodin ei myöskään tulisi heittää kuin enintään kahta eri poikkeustyyppiä, mielellään vain yhtä. Jos metodi heittää montaa eri poikkeusta, joita ei voi mitenkään esimerkiksi periyttämällä yhdistää, on se yleensä merkki siitä, että metodi tekee kerralla liian montaa asiaa. Tämä on vain tyyliseikka, mutta vaikuttaa kutsuvan koodin selkeyteen.
6. Omien virheenhallintamallien keksiminen on vihoviimeinen asia, mitä kannattaa tehdä. Esimerkiksi johonkin sessioon talletettuja virhekoodeja, joita voi aina välillä käydä ihmettelemässä kun kaikki on jo hissuksiin mennyt pieleen. Näitä näkee joissain vanhoissa muista kielistä konvertoiduissa sovelluksissa. Kaikkein loistavimmissa tapauksissa virhe on tosiaan vain jokin numerokoodi ja virheen oikea syy pitää kaivaa esiin jostain dokumentaatiosta: Ettei kehittäjä vaan vahingossa mene paljastamaan sitä käyttäjälle…
7. Tyhjiä catch-blockeja tulee välttää. Ne ovat hyväksyttäviä varsin harvoin (esim. sivuutettu NumberFormatException Stringien parsinnassa). Silloinkin on kohteliasta merkitä poikkeus tarkoituksella sivuutetuksi, tyyliin: catch (NumberFormatException ignored) {}. Muutoin poikkeukset on syytä vähintäänkin kirjata ylös.
8. Jos rajapinnan vuoksi joutuu muuntamaan poikkeuksen toisen luokan instanssiksi, kannattaa siihen liittää mukaan alkuperäinen poikkeus: new ExceptionalException(ex.getMessage(), ex);
9. Finally-blokeista tippuvia poikkeuksia on syytä varoa: Ne saattavat helposti piillottaa alkuperäisen try-blokista tippuneen virheen.

Artikkeli on luettu 599 kertaa. Kuuluu luokkiin: Java, Ohjelmointi