Java vs HTML 5 vs Flash

Olen pannut huvittuneisuudella merkille miten maailmalla kirjoitetaan artikkeleita Javan tuhosta. Alustalla on tietoturvahaavoittuvuuksia, se suositellaan siis poistettavan. Näin ollen Javan aika on ohi ja se vuotaa rahaa Oraclelta. Tässä lauseessahan on niin paljon väärin ettei tiedä mistä aloittaa. Javan pääkäyttöhän ei ole työasemissa vaan servereissä, jonne mm. IBM, Oracle ja RedHat ovat tehneet ja tulevat tekemään rahallisia panostuksia, ja joissa Java-pohjaiset web serverit ovat tyypillisimpiä alustoja web-sovelluksille, etenkin yrityspuolella. Ja jossa noilla mainituilla haavottuvuuksilla ei ole (juuri) mitään merkitystä. Java siis elää tai kuolee sen mukaan miten hyvin se suoriutuu palvelinohjelmoinnissa vastaan muita teknologioita, ja miten hyvin sitä puolta tuetaan ja kehitetään. Jos tänä päivänä java se tapettaisiin kokonaan, merkitys Javan kannalta ei olisi suuren suuri. Javan merkitys on servereissä, ei työasemissa. Tosin työasemissakin sekä mobiililaitteissa on Javaa asenneltuna miljardeja yksi

Väite: Pitäisikö sitten Java työasemista poistaa? Sehän on täynnä tietoturva-aukkoja ja joka kuukausi eletään pelossa löytyykö uusi. Lisäksi, kuka enää tekee rich client ohjelmointia, kun kaiken voi tehdä HTML5:lla? Adobekin luopuu flashistä. Java on ihan tarpeeton tekele?

Vai onko? Katsotaanpa tarkemmin näitä argumentteja:

Voiko kaiken todella tehdä HTML5:lla? Kenties voi. Perinteisesti rikasta käyttöliittymää lähdettiin tekemään Javalla tai Flashillä siksi että perinteinen HTML pohjainen web-sovellus on staattinen ja jäykkä, se reagoi vain napinpainallukseen ja pystyy ainoastaan näyttämään web sivuja ja ottamaan syötettä, ei esim. minkäänlaista pääsyä työaseman/mobiililaitteen rautaan kuten älykortinlukijoihin, (web) kameraan, paikkatietopalveluihin, yhteystietoihin, kalenteriin, värinärajapintaan, kiihtyvyysanturiin, kallistusanturiin, verkkokorttiin, äänikorttiin, piirtämiseen, videon soittoon, matalan tason tehokkaisiin grafiikkarajapintoihin, jne. JavaScript laajensi palettia antamalla mm. rikkautta tapahtumankäsittelyyn. AJAX lisäsi vielä lisää rikkautta kun dataa voi hakea dynaamisesti verkon yli ja sillä päivittää sivua ilman että täytyy edes navigoida. Ja HTML 5 lisää vielä lisää kuten Canvas piirtoalusta, ääni ja videorajapintoja, paikallinen tietovarasto. Sillä voi soitella videota ja ääntä, ja tehdä kaunista käyttöliittymää.

Mitä sitten uupuu? No pari asiaa. HTML 5 ei pärjää suorituskyvyssä lähempänä käyttöjärjestelmää ajetulle koodille, eli kun halutaan ottaa koneesta kaikki irti, se jää jälkeen. HTML5 pääsee vain niihin resursseihin käsiksi jotka on siihen avattu, eli aina kun joku uusi vimpain keksitään työasemiin tai mobiililaitteisiin, HTML5 sovellukset ovat jälkijunassa sen soveltamisessa. Samoin tietysti Java, mutta vähemmän kuin HTML. Esim. JavaFX teknologian suorituskyky on täysin eri planeetalta ja visuaalista ilmaisukykyä riittää eri sarjassa.

Pahimmat niitit tulevat kuitenkin tässä: HTML5 ei ole vielä edes valmis, se on tällä hetkellä vaporwarea kunnes toisin todistetaan. Sen spesifikaatiokaan ei ole valmis, se _ehkä_ tulee 2014. Selainvalmistajat _ehkä_ toteuttavat sen. Siihen mennessä _ehkä_ maailma ei ole muuttunut yhtään. Muistan myös 90-luvun suuret selainsodat, kun Dynamic HTML ja JavaScript olivat uusi ja kuuma juttu, ja valmistajat kilpailivat siitä kuka tekee hienoimmat toteutukset ja tulkitsee standardeja nerokkaimmin ja mahdollisimman epästandardein tavoin. 2014 web sivustot tulevat räjähtämään käsiin ellei ihmiskunta ja eritoten selainvalmistajat ja kehittäjät ole jotenkin viisastuneet siitä. Todennäköisesti joudutaan taas tekemään eri versiot sivustoista eri selainversioille, tätä on jo nyt näkyvissä vaikka speksi ei ole edes valmis.

Entäpä sitten tietoturvaongelmat? Javassahan on niitä, haavoittuvuuksia, jotka pitää paikata tai niitä hyödynnetään. Samoin on Windowsissa. Linuxissa. JavaScriptissä. Ja niin myös Ajaxissa ja eritoten HTML 5:ssa. Jos haluaa alustan jossa ei ole tietoturvaongelmia niin se onnistuu kunhan alustassa ei voi tehdä mitään. Mitä enemmän alustalla voi tehdä sitä rajummin siellä on potentiaalia tietoturva-aukoille, ja aukotonta järjestelmää ei olekaan. Miten nopeasti tulevat HTML5 aukot paikataan ja kenen toimesta?

No, siinä pohdittavaa. HTML5 on mielestäni mielettömän kaunis ja lupaava teknologia, mutta se ei ole mullistava eikä sovelluskehityksen pelastaja eikä missään nimessä ongelmaton. Siinä tulee olemaan tietoturvaongelmia ja vakavia sellaisia kun sen käyttö lisääntyy, samalla kun sen ominaisuudet muuttuvat paremmiksi. Suuren vallan mukana tulee suuri vastuu.

Monet artikkelit ja mielipiteet julistavat sokeasti HTML5:den uutta tulemista ja kaikkien rikkaiden käyttöliittymäteknologioiden kuten Flash, Applet, JavaFX kuolemaa, ja tämä on ehkä yksipuolinen näkemys. En halua myöskään väittää että JavaFX jyräisi HTML5:sen, tuskinpa vain. Hyvä jos sille tilaa riittää markkinoilla. Mutta HTML5 ei ole Suuri Pelastaja joka mullistaa kaiken. Se on yksi teknologia muiden joukossa, ja omaa samoja ongelmia kuin muutkin. Suorituskyky, pääsy uusiin rautaratkaisuihin ja rajapintoihin client päässä, todellinen siirrettävyys eri alustoilla kuten eri selaimet, käyttöjärjestelmät, ja eri valmistajien mobiililaitteet, sekä tietoturva, ovat kaikki haasteita, jotka tulee ratkaista. Yhtäkaikki ei ole huono juttu että 2015 vuonna työkalupakissa on useita hyviä uusia mahdollisuuksia.

Lähdelinkkejä ja lisäluettavaa:

Facebook liian aikaisessa HTML5:sen kanssa:
http://css.dzone.com/articles/facebook%E2%80%99s-html5-mistake

HTML5 suorituskykyä voidaan kiihdyttää:
http://www.html5rocks.com/en/mobile/nativedebate/

Green is good 😉
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)

Java vs HTML5 Canvas:
http://www.zynaps.com/site/experiments/mandelbrot.html

Kiihdytä Android kehitystäsi!

Jep, puuhaillessani Android III kurssin kanssa törmäsin hyvään artikkeliin. Uusimmissa Android kehitysympäristöissä on nimittäin pari lisäpiirrettä joilla saa emulaattoriin vauhtia, tietyissä olosuhteissa.

Android emulaattorihan on julmetun hidas. Se emuloi dalvik bytecode virtuaalikonetta linuxin päällä joka pyörii emuloidun arm prosessorin päällä. Tukkoista on. Intel on kuitenkin toimittanut virtuaalikoneen myös, jossa päästään lähemmäs rautaa jos ollaan Windows tai Mac alustoilla. Tähän saa erityisesti buustia kun asentaa ja kytkee HAXM managerin päälle, ja kytkee myös rautakiihdytetyn GPU emulaation päälle.  Jos koneessa ei ole tehoja tai hyvää kiihdytettyä grafiikkakorttia näistä ei juuri ole apua. Mutta jos näitä löytyy, saat kaiken irti.

Prosessi on helppo ja testattu: Avaa Android SDK asennustyökalu ja asenna sieltä Intel Atom virtuaalikone sekä HAXM (Intel Hardware Accelerated Execution Manager). Huom! Image on saatavana vain parille API versiolle, tällä hetkellä API 15 eli Android 4.03 ja API 10 eli Android 2.3.3 – mutta niillä pääsee jo pitkälle!

HAXM ei asennu automaattisesti, vaan asennusohjelma latautuu android sdk kansioon extras/intel alle. Asenna se. Jos asennus epäonnistuu, rauta ei ole yhteensopivaa.

 

Homma hoidossa? Hienoa, nyt voit palata Eclipseen tai muuten vain AVD manageriin ja luoda uuden virtuaalikoneen. Valitse siihen API Level 15 tai 10, Intel prossu, ja GPU kiihdytys päälle. Ei ole huono idea myöskään pajauttaa gigaa paria muistia jos sitä piisaa, tähän tapaan:

 

Homma hoidossa? GPU emulaatio päällä snapshotit eivät pelaa – mutta en käytä itse niitä muutenkaan epävakauden vuoksi ja nyt pitäisi käynnistymisen olla nopeampaa.

Ja perään se perinteinen ’lääkintöhallituksen varoitus’ – jos tapat koneesi asennellessasi näitä en kanna yhtikäs mitään vastuuta. Ja android softan testauksessa emulaattori on vain yksi väline, pitäisi aina testata aidolla raudalla. Mutta onhan tuo penteleen mukavaa että ensikierroksen testaus on nopeutunut silmin nähtävästi! Ensikäynnistys vei hetkisen edelleen, mutta toistuvat käynnistykset.. Omalla koneellani puhutaan n. 10 sekunnin ajasta. Ehkä 20 sekuntia että kaikki on käynnissä. Ja käyttö on yhtä nopeaa ja miellyttävää kuin Galaxy III:lla 😉 Tämä on hyvä vinkki myös jos puuhailet paljon mobiili web-sivustojen testausta ja puljaat virtuaalikoneiden kanssa. Puhutaan noin 2-3 kertaisesta nopeutuksesta vähintään jo ennestään nopeutuneeseen myllyyn.

 

Jep, ja loppuun lähdelinkki alkuperäiseen artikkeliin:

http://www.developer.com/ws/android/development-tools/haxm-speeds-up-the-android-emulator.html

Ja Android 3 kurssi on valmis ja kimaltelee jo kurssitarjonnassa sisältäen kaikkea hauskaa kuten NFC ja Face Detection 😉

http://www.tieturi.fi/kurssit/kurssi.html?course=85000210&category=Mobiiliteknologiat

 

First rule of exception handling: Do not do exception handling!

Error: There is no error!

Tästä onkin pitänyt jo hetken aikaa pistää ajatuksia ylös, koulutuksissa aiheesta aina saarnaan mutta yritetään koota ajatuksia enemmän tai vähemmän koherentisti jopa artikkelin muotoon. Lainasin iskevän Fight Club henkisen artikkelin toisesta paikkaa, mutta ajatukset ovat ihan omia. Niissähän voi olla myös mielipiteitä ja jopa väärinkäsityksiä, eli tunne olosi vapaaksi kertoa mielipiteitäsi 😉 😉

NullpointerException at line 5872/Error: There is no error!

Konsulttihommissa ja ihan vain käyttäessä kotimaisia ja ulkomaisia web-sovelluksia on tullut nähtyä mitä kauheampia lähestymistapoja virhekäsittelyyn. Alkaen ohjelmiston kaatumisesta ja stacktrace-virhepinosta ruudulla tai lähdekoodin näkemisestä ihan vain tyhjään valkoiseen sivuun tai klassisiin: generic error, something unexpected happened tyyppisiin. Kun virhekäsittely on tehty huonosti, se luo suunnattomia tietoturva-haavottuvuuksia, ja luo ohjelmistosta myös huonolaatuisen ja epävakaan kuvan käyttäjille – mikä kaiken lisäksi on useimmiten totta.

Takaisin polulle

Miksi sitten virhekäsittelyä ei tehdä oikein? Kun projektin aikataulupaineet puskevat päälle mennään usein kiireen alla koodaamaan ja silloin saattaa olla että keskitytään vain siihen yhteen ainoaan happy-skenaarioon testauksessa, siihen kun kaikki toimii. Yhtä tärkeää olisi myös miettiä polut: Mikä voi mennä pieleen. Testata ne, rakentaa niille käsittelyt jotka mahdollisimman sulavasti ohjaavat käyttäjän taas tuottavalle polulle. Tässä onkin virheiden käsittelyn tärkein oppi (ja hyvä neuvo elämässä noin muutenkin). Älä keskity siihen mikä meni pieleen – keskity siihen miten normaalitoiminta voi taas jatkua.

Sovelluksessa tapahtuvat epänormaalit tilanteet johtuvat tyypillisesti kahdesta eri asiasta: Käyttäjästä, tai olosuhteista. Edelliset eivät ole oikeastaan virheitä, vaan väärinkäsityksiä, jotka pitää lempeästi ohjaten oikaista. Jälkimmäiset taas ovat asioita joista käyttäjälle on tarpeetonta tiedottaa näyttäen poikkeuspinoa ja koodin rivinumeroita: Loggaa niiden tekniset yksityiskohdat talteen, korjaa ne välittömästi jos pystyt, tai jos et pysty, kerro käyttäjälle että järjestelmässä on ongelmaa, anna ohjeet miten tästä voi edetä, ja mielellään tiketti jolla logiviestit voidaan jäljittää.

Opasta käyttäjää lempeästi

Ohjaa siis käyttäjä takaisin tuottavalle polulle. Se tarkoittaa että ennakoit mahdollisia virhetiloja. Tuliko syöte joka ei ole sallittu? Opasta käyttäjää hyvin esimerkein. Älä anna sovelluksen kaatua ylimääräiseen heittomerkkin tai pienempi-kuin merkkiin. Älä tyhjennä syötettyä lomaketta tiedoista ja näytä käyttäjälle virheilmoitusta tyyliin: ”Syötteessä oli virhe. Yritä uudelleen”.  Hyvä virhekäsittely ei hävitä jo syötettyjä tietoja mutta näyttää tarkalleen missä syötevirhe oli ja mieluiten hyvän esimerkin kera millaista syötettä tässä odotetaan. Esim. puhelinnumerot, päivämäärät, numerot menevät herkästi sekaisin, ja väärinkäsityksen vuoksi merkkijono voi olla aivan liian lyhyt tai pitkä. Tarkista myös että syötetyt merkit ovat järkeviä sovelluksen kannalta: Unicodessa on n. 65 000 merkkiä joista periaatteessa jokainen voi olla turvariski väärissä olosuhteissa. Ehkä siis on parempi olla tarkistamatta erikseen vaarallisia merkkejä, ja sensijaan miettiä tarkemmin mikä on sallittua.

Jotain odottamatonta tapahtui – odota hetki ja yritä uudelleen, tai ota yhteys ylläpitoon

Kun jotain odottamatonta menee pieleen se voi johtua esim. odottamattomasta kuormituksesta, verkkoyhteyksien menettämisestä, sähkökatkoksesta, odottamattomasta uudelleenkäynnistyksestä, viiveiden aiheuttamasta timeoutista, siitä että joku kompastui verkko tai sähköjohtoon, kovalevy hajosi, etc. Mikään näistähän ei ole oikeasti odottamatonta, eihän? Näitä tapahtuu, ja näitä voi myös testata. Voit tarkistaa miten sovelluksessasi näkyy kun kantapalvelin ajetaan alas tai joku osakomponentti hajoaa tai sammuu. Kuormitusta voidaan simuloida ja vasteaikoja testata. Toisin sanoen, kun odotettuja odottamattomia virhetiloja ilmenee, hyvin tehty järjestelmä kertoo käyttäjälle riittävästi, loggaa yksityiskohdat talteen, ja tarvittaessa hälyttää ylläpidon jotta jotain voidaan tehdä. Ja kun jotain todella odottamatonta tapahtuu, prosessi on periaatteessa sama mutta ehkä kiireisempi. On mahdollista tehdä geneerinen virhekäsittely joka kattaa loput tilanteet joita ei todellakaan osattu odottaa. Miten nopeasti virheen sattumisesta päästään taas takaisin tuottavalle polulle? Siinä erottuvat jyvät akanoista.

Virheiden käsittelyn Antipatterneja

Sanaa antipattern en edes yritä suomentaa (Vastahahmo? ;), mutta on tullut nähtyä kooditasolla levinneitä turmiollisia lähestymistapoja siihen miten virheitä käsitellään. Mitä vikaa on seuraavissa malleissa?

try {
      // Some code that causes errors here
} catch (NullPointerException npe) {
} catch (ArrayIndexOutOfBoundsException aiooe) {
      aiooe.printStackTrace();
} catch (Exception ex) {
      showErrors("Connection failure, please try again");
}

Hoksaatko mitään turmiollista? Siinä on ainakin kolme antipatternia käytössä. Osa näistä johtui Java kielen valitettavasta visiosta käyttää checked exception mallia eli pakko-käsitellä tyyppisiä poikkeuksia. Se on saanut ohjelmistokehittäjät generoimaan usein tarpeettomia try-catch-lauseita, piilottelemaan poikkeuksia, käsittelemään niitä kun ei ole aika käsitellä, ja käsittelemään niitä huonosti. Mikä meni pieleen?

– Huomasit varmaan tyhjän catch-lohkon. Sellaisia löytyy jopa tuotantokoodista. Oletan että syynä on, että poikkeus laukeaa herkästi mutta on suhteellisen harmiton joten se lakaistaan maton alle. On ehkä 1 tapaus 100:ssa missä on perusteltua tehdä sellainen, eli poikkeus pitää piilottaa. Sellainen poikkeuksellinen tilanne pitäisi kuitenkin dokumentoida ja sen pitäisi olla harvinaisuus, ei yleinen käytäntö. Jos jotain menee pieleen, ja piilotat sen, ongelma ei ole poistunut, ja se tyypillisesti rantautuu myöhemmin jossain muualla mitä mielikuvituksellisimmin tavoin, ja tekee alkuperäisen syyn löytämisen äärettömän vaikeaksi. Se harvinainen tilanne jossa tuo voi olla ok on jos pitää tulla toimeen taustajärjestelmän päällä joka jostain syystä käyttää poikkeuskäsittelyä väärin, ei kerro virhetiloista vaan tekee niillä jotain muuta. Tyhjä catch lohko on paholaisesta.

– Toinen antipattern on äärimmäisen yleinen ex.printStackTrace() kutsu, generoituna suoraan Eclipsestä. Se toimii kehittäjän koneella hienosti, kun virhepino menee konsoliin, mutta asennettuna ei konsolia olekaan. Jos kyseessä on android tai palvelinsofta, virheet tulostuvat logiin. Mutta kukaan ei ehkä koskan katsele logia. Tai jos katselee, merkityksellinen tieto hukkuu sadantuhannen stacktrace tulostuksen alle. Ei näin. Tämä on oikeastaan variaatio edellisestä eli tyhjästä catch lohkosta. Mitä pitää tehdä kun havaitaan poikkeus? Pysähdy, pistä detailit logiin jos virhe todella johtuu ympäristöstä tai on syytä logata. Korjaa ongelma jos se on korjattavissa. Jos ei ole, tiedota niitä jotka pystyvät sen korjaamaan. Ellet pysty tekemään mitään näistä, kuplita virhe eteenpäin tasoon jossa voidaan näin tehdä, yleensä UI taso. Tiedota ylläpitoa jos tarpeen. Tiedota käyttäjää aina. NullPointerException ei kerro mitään käyttäjälle (toivon mukaan), muista kertoa miten tästä päästään eteenpäin eikä sitä mikä meni vikaan.

– Kolmas antipattern yllä on catch-all lohko. Sitä näkee usein ainoana try-catch lohkona, ja usein viimeisenä käsittelynä kuten yllä. Tällekin voi olla joskus perusteensa, mutta useimmiten sitä käytetään aivan liian aikaisin. Catch-all lohkon ongelma on että se todella saa kaikki virheet kiinni, mistä ikinä ne johtuivatkaan. Jos se on liian aikaisin otettu käyttöön, siihen sisältyy röyhkeä oletus että pystyt käsittelemään minkä hyvänsä virheen samalla kaavalla. Mikä voi olla totta, mutta ellei se olekaan, olet taas piilottanut ongelmia muiden alle. Eli käsittely on ok kun todella haluat käsitellä kaikki jäljellä olevat ongelmat, käsittely on väärin kun otat laajasti kiinni mutta sovellat suppeasti virheen näyttöä, kuten yllä.

Mikään ylläolevista ei ole 100% ajasta tuhoisa tai edes väärin, kyse on nyansseista.

Suosituksia poikkeuskäsittelyyn

Älä ota poikkeuksia kiinni liian aikaisin. Jos et ole valmis korjaamaan ongelmaa tai keskustelemaan käyttäjän kanssa, heitä sama poikkeus tai uusi poikkeus uudelleen, kuplita, delegoi seuraavalle kutsupinossa kunnes päästään paikkaan missä voidaan korjata ongelma tai keskustella käyttäjän kanssa siitä miten se korjataan.

Älä loggaa samaa ongelmaa kahdesti tai useammin, kerta riittää. 

Paras tapa saada aikaan hyvä poikkeuskäsittely on hyvä testaus. Kehitä automatisoidut testit käyttöliittymään ja simuloi virheellisiä syötteitä ja muita virhetiloja siinä missä onnistumistakin. Kehitä myös kuormatestausta. Näin näet miten ne ilmenevät käyttöliittymässä, ja bonuksena tällaisten testien uudelleenkäytettävyysarvo on erinomainen. Testaa, testaa, testaa.

– Käyttäjävirheitä jotka johtuvat esim. validoinnista ei yleensä kannata logata (ja tukkia logia tarpeettomalla hälyllä), vaan keskity ohjaamaan käyttäjä oikealle suorituspolulle takaisin. Älä keskity siihen mikä meni pieleen, vaan keskity ohjaamaan käyttäjää miten toimia oikein, hyvän esimerkin kera. Jos käyttöliittymäsi käyttää idioottivarmoja kontrolleja tiedon keruuseen ja omaa hyvän validointilogiikan, voi olla että käyttäjävirheitä ei juuri tapahdu. Pyri siihen että käyttäjän aiheuttamat virheet eivät aiheuta poikkeuksia.

– Järjestelmä ja ympäristövirheet ovat vakavia, ja usein toiminnan pysäyttäviä. Käyttäjä harvoin voi niitä itse korjata. Osa virheistä voi korjautua itselläänkin, mutta tyypillisesti on hyvä logata yksityiskohdat, herätellä joku ylläpidosta tekemään jotain. Jos automatiikka ei siihen riitä, manuaalinen tapa on näyttää käyttäjälle geneerinen sivu jossa on ylläpidon yhteystiedot ja tikettinumero. Tässä tapauksessa älä anna käyttäjälle yksityiskohtia jo tietoturvasyistäkään, mutta loggaa ne huolella, ja pidä huoli että asialle tehdään jotain nopeasti.

– Sitten on ryhmä, todella odottamattomat virheet. Jos näihin yleensä pystyy reagoimaan, lähestymistapa on jotakuinkin sama kuin yllä, sillä erotuksella että nyt on KRIITTISTÄ pistää tietoa ylös virheestä ja nopeasti saada korjausta aikaan. Nämä tulisi myös logissa nostaa selkeästi omaan kategoriaansa että johtolangat löytyvät selkeästi. On ihan ok tehdä koko pinon päälle vielä geneerinen catch-all lohko joka ottaa kiinni kaikki todella odottamattomat virheet – jotta käyttäjän ruudulle ei pauku poikkeuskoodeja ja pinoja. Se ei vain saa olla ainoa poikkeuskäsittelymalli. Pidä myös huoli että käsittely tallettaa riittävästi yksityiskohtaista tietoa siitä mikä meni vikaan.

Siinäpä se. Suorituskyvyn suhteen on myös hyvä muistaa että poikkeuksien heittäminen ja etenkin poikkeuksen ottaminen kiinni ja heittäminen uudelleen on erittäin tehosyöppöä. Mutta sovelluskehityksen ensimmäiset prioriteetit ovat toimivuus ja selkeys, ja kuten opetan kursseilla, optimointia ei pidä lähteä tekemään ellei siihen ole syytä. Jos on, poikkeuskäsittelyn minimointi antaa vastalahjaksi usein suoritusnopeutta lisää. Tästä on kirjoitettu lukemattomia artikkeleita jos aihe kiinnostaa.

Muutamia muita hajatuksia aiheesta:

http://mikehadlow.blogspot.fi/2009/08/first-rule-of-exception-handling-do-not.html

http://today.java.net/article/2006/04/04/exception-handling-antipatterns