Checked exception itu idenya luhur, tapi pada prakteknya flawed.
1. Inheritance
Base-class/interface itu gak pernah bisa tau subclass apa yang bakal
implement dia. Ngasih assumption tentang exception yang bisa/gak bisa dia
throw itu mestinya bukan responsibility base-class. Misalnya class
EntityRepository base-class, gak make sense buat dia define throw
SqlException (database-subclass), ato IOException (file-system subclass),
ato RemoteException (WS/REST). Base class tau terlalu banyak.
Dan juga yang paling common adalah kalo gw ketemu getter/setter yang gak
throw apa2, tapi mesti gw extend dengan smart implementation di dalemnya
(misalnya caching/lazy-load/security), dan sekarang lu stuck dengan "no
exception" restriction.
Ini juga termasuk saat ngedecorate ordinary classes dengan dynamic proxy
yang infrastructure-specific. Lu tiba2 mesti struggle cari cara supaya bisa
bubble up infrastructure-related exceptions ini ke atas.
Message gw adalah, lu gak bisa antisipasi class yang hari ini gak throw
apa2, besok bakal diextend oleh class laen dengan implementasi berbeda.
2. Exception wrapping
Ini yang nambahin noise dimana2. Lu mesti anticipate bahwa implementation lu
bakal throw some sort of exceptions. Jadi lu define semua method lu supaya
throw custom exception. Dan tiap exception di tiap method bakal lu bungkus
ke exception ini. Pertama, ini beats the purpose dari checked exception in
the first place. Kalo tiap method lu jadi bisa throw exception apa ajah
(tapi dibungkus), apa bedanya dengan unchecked exception? Kedua, exception
yang dibungkus itu bikin susah buat lu supaya bisa catch specific type of
exception. Misalnya, on network-exception then retry seluruh transaction.
Tapi kalo sql-exception, lu mo langsung abort.
3. Rethrow
Kadang lu pengen punya generic policy buat handle segala jenis exception
sebelom di bubble up. Ini yang gw mau:
public void someMethod() throws ExceptionA, ExceptionB, ExceptionC,
ExceptionD
{
try
{
// some operation
}
catch(Exception e)
{
// handle something
throw e; //bubble up
}
}
Tapi karna checked exception, gw dipaksa buat repeat myself dengan code
noise yang ugly banget.
public void someMethod() throws ExceptionA, ExceptionB, ExceptionC,
ExceptionD
{
try
{
// some operation
}
catch(ExceptionA e)
{
// handle something
throw e; //bubble up
}
catch(ExceptionB e)
{
// handle something exactly same way
throw e; //bubble up
}
catch(ExceptionC e)
{
// handle something exactly same way
throw e; //bubble up
}
catch(ExceptionD e)
{
// handle something exactly same way
throw e; //bubble up
}
}
Code noise yang violate DRY banget... Tiap catch block isinya sama semua.
Definisi code noise adalah, code yang disitu gak buat nambahin value apa2,
tapi cuma mesti duduk disana stupidly buat bikin compiler seneng.
2009/9/9 Thomas Wiradikusuma <wiradikusuma.mi...@gmail.com>
>
>
> OOT, tapi gw kasih insight aja IMO.
>
> pada awalnya, desainer bahasa Java sengaja membuat Exception itu
> checked (kecuali RuntimeException)
> supaya developer aware dg exception dan menghandlenya properly. mereka
> pikir, "repot dikit gpp, yg penting selamet."
>
> nah sialnya, in practice banyak yg ogah ngurusin exception, akhirnya
> dilempar2 terus ke atas atau cuma ditelen.
> jadinya too much boilerplate. mulai kembali deh ke tren unchecked.
>
> contohnya, di Groovy, anaknya java, checked exception java dibungkus
> jadi unchecked.
>
>
> ----
> salam hangat,
> Thomas Wiradikusuma
> Twitter: http://www.twitter.com/wiradikusuma
> Blog: http://www.jroller.com/wiradikusuma
>
> On Sep 9, 2009, at 1:12 AM, in_harmonia wrote:
>
> > Sori agak OOT, tapi terlepas dari good practice atau bukan, bukannya
> > Java punya checked exception yang artinya "pengecualian yang
> > diharapkan" :D
> >
> > --- In jug-indonesia@yahoogroups.com <jug-indonesia%40yahoogroups.com>,
> Daniel Baktiar <dbakt...@...>
> > wrote:
> >>
> >> sebaiknya pakai if else, kalau tidak salah exception handling jauh
> >> (beberapa
> >> puluh atau ratus kali) lebih lambat.dan exception dibuat benar2
> >> untuk hal
> >> yang pengecualian, bukan yang diharapkan.
> >>
> >> kalau dalam hal ini definisi mapping hibernate membolehkan adanya
> >> null,
> >> berarti nilai null diharapkan dan bukan pengecualian.
>
>
>
