Btw.. .point#2 sebenernya gw bring up sebagai common answer dari problem#1.
Masalahnya, itu bukan solusi, melainkan clever workaround buat men-*disable*
fitur checked exception dengan cara ngebungkus semua exception jadi custom
exception. Jadi bisa mengcater semua possiblities dari segala exception yang
subclass kita bakal deal with.
Gw sering annoyed kalo liat base-class yang cuma throw SqlException
misalnya. Dan sekarang gw mesti extend itu class jadi pake web-service. Gw
jadinya mesti ngebungkus AxisException ke dalem SqlException.... Silly..
Silly!

2009/9/9 Hendry Luk <hendrym...@gmail.com>

> 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.
>>
>>  
>>
>
>

Kirim email ke