Java crumbs

Každý problém v programování můžeme vyřešit přidáním další vrstvy abstrakce

Každá netriviální abstrakce do určité míry prosakuje.
Zákon prosakujících abstrakcí (Joel Spolsky)

Prosakující (děravá, leaky) abstrakce je termín, který zpopularizoval Joel Spolsky ve svém článku „Zákon prosakujících abstrakcí“. O co jde? V programování a obecně v informatice si potrpíme na abstrakce. Uvedu příklad ze světa Javy. Používáme ORM nástroje jako je Hibernate. Ty nám krásně odabstrahují všechny ty složitosti za tím. Nemusíme vědět nic o JDBC, SQL, Oraclu nebo Solarisu, stačí nám znát JPA a o zbytek je ukryt za stěnou abstrakcí. Prostě si jenom žijeme v krásném objektovém světe a od hrůz vrstev které jsou pod námi jsme odstíněni. To je ovšem pravda jen dokud nedojde k problémům. Jakmile něco přestane fungovat, začnou k nám prosakovat vrstvy od kterých jsme byli původně odstíněni. Takže musíme vzít kladivo a prosekat se na místo kde problémy vznikly. Takže se najednou musíme začít zabývat nastavením JDBC nebo efektivitou generovaných SQL příkazů. Když je problém hodně exotický, tak si musíme nastudovat jak fungují transakce v Oraclu, indexy nebo dokonce souborový systém v Solarisu. Ocituji Joela:

Všechno tohle paradoxně znamená, že ačkoliv máme programovací nástroje stále vyšší a vyšší úrovně s vyšší a vyšší úrovní abstrakce, je stále těžší a těžší stát se dobrým programátorem.

Kdysi programátorovi stačilo umět JDBC a SQL. Pak přišli ORM nástroje a od JDBC ho odstínili. No jo jenže chudák programátor potřebuje řešit problémy. Takže mu nestačí znát jen ORM, musí se orientovat i ve vrstvách pod ním. Dnešní programátor tak toho musí umět víc než kdysi.

No a proč to vlastně píšu. Narazil jsem na úplně úžasný příklad prosakujících abstrakcí. Mám notebook s Ubuntu. Když jdu ve Firefoxu na stránky grails.org, celý systém na pár sekund úplně zatuhne. Když se podívám co se v děje, tak vidím, že X Windows žerou 100% procesoru. Ostatní stránky ale fungují normálně. Evidentně je tedy chyba na stránce grails.org. No ale v ostatních prohlížečích stránka funguje skvěle. Takže by to bylo Firefoxem? Ale na Windows to ve Firefoxu funguje dobře. Tak že by za to mohlo Ubuntu? Jiné prohlížeče nemají s danou stránkou na Ubuntu problém. Tak čím to může být? Záhada. Naštěstí máme Google. Ten nám prozradí, že se to děje v pouze v kombinaci nVidia grafická karta, nVidia proprietární ovladač, Linux a grails.org nebo pár dalších stránek. Vypadá to, že grails.org mají v kaskádovém stylu (CSS) zadanou nějakou nesmyslně velkou hodnotu, kterou daný ovladač špatně vyhodnotí a začne počítat na CPU místo na grafické kartě. Nebo tak něco.

V tomto případě nám prosákly detaily práce grafické karty až do CSS. Zkrátka průsak skrz celý notebook. Teď si představte, že by se vám stalo něco podobného při vývoji interní aplikace. Google by vám v tom případě nepomohl. Měli byste jen chybové hlášení od pár uživatelů a vůbec byste mu nevěřili. Vždyť to všem ostatním funguje. Vždyť je to webová stránka, ta je přeci nezávislá i na operačním systému, natož pak na hardware. A ono ne. Ovladač grafické karty, operační systém i prohlížeč jsou jen vrstvy abstrakce. A jelikož jsou netriviální tak občas prosakují.

Dnes budu psát o zpětné kompatibilitě v Javě. Předem upozorňuji, že nejsem expert na dané téma, spíš si chci jen ujasnit myšlenky. Takže když někdo narazíte na chybu v mých jinak bezchybných myšlenkách, tak to prosím pěkně rozmázněte v diskuzi pod článkem. Rád se něco přiučím.

Co to tedy je zpětná kompatibilita? Zpětná kompatibilita je, když moje staré programy běží i v novém prostředí. Kdo chce vznešenější definici, ať si ji laskavě najde sám. Jednoduchý příklad. Vezmu starou hru pro DOS a pustím jí ve Windows. Když poběží, vím že byla zachována zpětná kompatibilita, když ne, tak si přečtu skvělý článek od Joela, v kterém vysvětluje proč tomu tak není.

V Javě se její autoři snaží zpětnou kompatibilitu zachovávat. Ale aby to nebylo tak jednoduché, tak hlavně binární. To znamená, že program zkompilovaný pod Javou 1.4 spustím v JRE verze 6. Super. Samozřejmě naskytnou i výjimky, ale je velká pravděpodobnost, že ten program poběží. Což potěší naše zákazníky. Ti mohou program, který před lety draze zakoupili, používat i na nejnovějších JRE.

To je binární kompatibilita. Ale co zdrojáky? Ty by teoreticky měly být taky kompatibilní. Měl bych být schopen zkompilovat staré zdrojové kódy novým JDK. Tady už můžu narazit na víc problémů. Naštěstí se je SUN snaží vyjmenovat v dokumentaci (Java 5, Java 6). Takže to vypadá, že i na straně zdrojových kódů by mělo být vše v pořádku. Tedy až na pár obskurních případů.

To by bylo taky super, kdyby to ovšem byla pravda. V té dokumentaci se tak nějak zapomněli zmínit, že přidávají metody do existujících rozhraní. Nejlépe je to vidět na třídě java.sql.Connection. Pokud jenom používáte instance tříd implementujících toto rozhraní, tak je všechno v pohodě. Pokud si ho ale troufnete implementovat sami, narazíte na problém (viz. tento chudák). V nové verzi vaše implementace nebude úplná, bude jí chybět pár metod. Pokud namítáte, že není moc časté implementovat si JDBC driver, tak si představte, že chcete vytvořit prachobyčejný wrapper. Třeba kvůli logování. To je věc, s kterou už se v životě můžete setkat. Váš wrapper bude skvěle fungovat do té doby, než se ho pokusíte zkompilovat pod novou verzí. Kompatibilita na úrovni zdrojového kódu jde do háje. Nejen to. Představte si situaci, kdy ten wrapper bude zkompilovaný ve staré knihovně, kterou jen používáte. Když zavoláte třeba Connection.getNClob(), tak to samozřejmě spadne. To už není tak super.

(Měl bych brzdit, aby se na mě Roumen zas nenaštval.) Ono udržet zpětnou kompatibilitu a zároveň jazyk rozvíjet je hodně těžké. Možná i nemožné. Můžeme si vybrat to nebo ono, obojí mít nemůžeme. Proto se ozývají hlasy, že by Java měla zpětnou kompatibilitu zahodit. Já s nimi nesouhlasím. Občas se totiž pohybuji mezi konzervativními klienty. Nedávno se mě jeden člověk od AS400 zeptal něco v tomto smyslu. „My máme program v Cobolu, který je asi dvacet let starý. Nejen že jsme schopni ho dodnes provozovat, ale i upravovat. Je něco podobného možné i v Javě?“ Jako odpověď jsem blekotal něco v tom smyslu, že když bude mít všechny knihovny a kompilátor a JRE tak asi ano. Ale moc jistý si nejsem. A to jsme naštěstí nezabrousili do témat jako je podpora starších verzí atp. (pokud se chcete vyděsit, klikněte zde).

Takže abych to uzavřel, zpětná kompatibilita je dobrá věc. Nikdy se ale nedá udržet na 100%. Tedy dá, ale jen za cenu stagnace. Jak tak sleduji situaci kolem vývoje Javy, tak stojíme na křižovatce. Rozhoduje se jestli chceme stagnovat nebo se chceme vyvíjet. Nerad to přiznávám, ale jsem spíš pro tu stagnaci. Respektive velmi opatrný vývoj. Pokud chcete nové cool věci, používejte třeba Groovy. To mi připadá jako rozumný kompromis. Konzervativci zůstanou u Javy a ti ostatní se mohou vrhnout na neprobádaná pole skriptovacích jazyků. Když je budou pouštět v JVM tak se za nimi možná časem vydají i ti konzervativci.

Už dlouho jsem nikoho nepoučoval a trochu mi to chybí, takže dneska budu psát o kontrolovaných alias synchronních alias čtverečkovaných alias checked výjimkách. Ano o těch výjimkách, které jste překladačem nuceni odchytit a zpracovat.

Teď pracuji s pěkně starým kódem. Jeho autoři si mysleli, že jsou kontrolované výjimky dobrý nápad, takže je hojně využívali. Já se jim nedivím, na první pohled se líbily i třeba Bruce Eckelovi. A nejen jemu, spousta důležitých knihoven v Javě je také hodně používá. Jenže já je nemám rád. Ukažme si to na příkladu ze života.

Představme si že píšeme finanční aplikaci která má být hyperrobustní. Vytovříme si třídu Money, do které budeme ukládat peníze. A to nejen množství, ale i měnu. Už při vytváření instance může nastat chyba. Filuta uživatel mé skvělé peněžní knihovny se mi může snažit podstrčit neexistující měnu. Jenže já nejsem žádný jakýpak copak, já mu na to přijdu a vyhodím mu CurrencyException. A abych mu ukázal, že se to může stát, tak udělám CurrencyException kontrolovanou (checked). Takže on musí počítat s tím, že mu ji vyhodím a správně ji zpracovat. Skvělé. Dokonce mohu i napsat metodu add, která si bude kontrolovat, jestli sčítám stejné měny a když ne, vyhodí mojí oblíbenou CurrencyException.

	public Money(float value, String currency) throws CurrencyException {
		//value should be BigDecimal, float is used for simplicity
		validateCurrency(currency);
		this.value = value;
		this.currency = currency;
	}

	public Money add(Money other) throws CurrencyException
	{
		if (!other.getCurrency().equals(getCurrency()))
		{
			throw new CurrencyException("Currencies do not match.");
		}
		return new Money(getValue() + other.getValue(),getCurrency());
	}

Takže mám super kód, který nutí ostatní programátory zabývat se tím, co se stane, když se pokusí míchat americké dolary a polské zloté. Ať žijí kontrolované výjimky! To si ovšem budeme říkat jen do doby než začneme tuto třídu používat. Nebo než uvidíme kód který ji používá. Setkáme se s podobnými perlami:

		Money money1 = null;
		try {
			money1 = new Money(123, "EUR");
		} catch (CurrencyException e) {
			//can not happen
		}
		Money money2 = null;
		try {
			money2 = new Money(121, "EUR");
		} catch (CurrencyException e) {
			log.log(Level.SEVERE, e.getMessage());
		}
		Money money3;
		try {
			 money3 = money1.add(money2);
		} catch (CurrencyException e) {
			throw new IllegalStateException(e);
		}

Při vytváření instance money1 si programátor zjevně myslel, že výjimka nemůže nastat. Vždyť tam má to euro natvrdo. Tak ji ignoruje. Tento případ je ze všech nejhorší. O trochu lepší případ nastane, když výjimku zapíše do logu jak to udělal v případě money2. Ale i tak, pokud při vytváření money2 dojde k výjimce, program bude pokračovat jen proto, aby o kousek dál skončil s NullPointerException. To je ta lepší varianta. V horším případě k NPE dojde o velký kus dál a my si budeme marně lámat hlavu, jak se nám tam dostal null. Asi nejlepší ze špatných řešení je použito u money3. Ali i to je špatně čitelné a ošklivé. Už chápete proč nemám rád kontrolované výjimky? Pokud by CurrencyException byla potomkem třeba IllegalArgumentException, kód by vypadal takto:

		Money2 money1 = new Money2(123, "EUR");
		Money2 money2 = new Money2(121, "EUR");
		Money2 money3 = money1.add(money2);

Nejen že to je lépe čitelné, ono je to i mnohem bezpečnější. Pokud dojde k té nepravděpodobné události a něco se pokazí, dozvím se o tom ihned. A pokud výjimku neodchytím někde o kus dál, tak se o tom dozví bohužel i uživatel. Ale i to je mnohem lepší, než aby se aplikace tvářila jako že funguje.

Pokud vám uvedený příklad připadá umělý, podívejte se na konstruktor java.net.URL nebo na jakýkoliv JDBC kód. Nebo klasický příklad s kódováním.

		Writer writer = null;
		try {
			writer = new OutputStreamWriter(out, "UTF-8");
		} catch (UnsupportedEncodingException e) {
			//can not happen
		}

Co se stane když vaše JVM nebude znát UTF-8? Správně, dostanete NullPointerException. S trochou štěstí po pár minutách debugování zjistíte co se děje. Když štěstí mít nebudete, tak vám to může zabrat i den.

Takže abych to shrnul. Kontrolované výjimky se mohou používat v jediném případě. Pokud jsem si jist, že programátor který ji odchytí bude vždy vědět co s ní má dělat. Což je asi důvod proč v C# kontrolované výjimky vůbec nejsou. Na celé záležitosti je navíc matoucí to, že ve skutečnosti máme opravdu dva druhy výjimek.

Jeden druh je obvykle způsoben špatnými vstupními daty. V takovém případě má smysl vyhazovat kontrolovanou výjimku a donutit programátora ji nějak zpracovat.

Jenže pak tu máme chyby způsobené chybou v kódu, konfigurací, selháním sítě, disku a podobně. V takovém případě nemá cenu výjimku obvykle chytat, protože beztak nevíme co s ní.

To by napovídalo, že pro chyby prvního typu bychom měli používat kontrolované výjimky, pro chyby druhého typu běhové (runtime) výjimky. EJB specifikace tak dokonce funguje. Podle typu výjimky dělá nebo nedělá rollback transakce (pokud ji neřekneme jinak).

Finta je v tom, že dopředu nikdy nevíme, ke kterému druhu chyby může dojít. Vraťme se k příkladu s penězi. Může se stát, že nám špatná měna přijde z jiného systému v XML. Pak má smysl vrátit specifickou chybovou hlášku a používat kontrolovanou vyjímku. Stejně tak může být měna načtena z konfiguračního souboru. Pak obvykle nemá smysl se výjimku nějak speciálně zabývat, aplikace je prostě nefunkční. Hláška v logu je naprosto dostačující.

Takže opakuji, nikdy dopředu nevíme jestli bude moci programátor používající náš kód umět výjimku zpracovat. Pravděpodobnější je, že to nedovede a provede s ní něco ošklivého. Proto se přikláním k názoru, že by kontrolované výjimky měly být používány zřídka, nejlépe vůbec. Běhové výjimky jsou bezpečnější a kód je s nimi mnohem čitelnější. Nicméně pokud má někdo nějaký příklad, kde si je jist, že by měly být za všech okolností použity kontrolované výjimky, sem s ním, rád se poučím.

Zdroje (aneb důkaz, že nosím dříví do lesa):

Does Java need Checked Exceptions?

Java theory and practice: The exceptions debate