Whoa, ga tau kalo masalah performance, tapi cara ke-2 seram... maen hajar aja
catch Exception, RuntimeException kena juga tuh, termasuk LIE.
--- In jug-indonesia@yahoogroups.com, Harry Christian wrote:
>
> Hi JUGers,
>
>
> Mau tanya nih. Saya mengalami masalah klasik yaitu Null Pointer.
>
> N
Afaik, dulu pernah ada dosen gw yang bilang kalo try-catch itu 10x lebih lambat
daripada if-else. Tapi ga tau juga, belum pernah membuktikan secara menyeluruh.
Tapi IMO kok code 1 dan code 2 di bawah sepertinya kayak beda tujuan yah?
> public void setDeptName (String deptName)
> {
>// Cara 1
> Inti pertanyaan saya lebih efesien dan lebih cepat mana antara cara 1
> (if else) ataukah cara 2 (try catch) ?
>
Kalo efisien mungkin lebih baik if else. (Mungkin lho ya..). Detail pastinya
saya belum pernah buktiin.
Tapi.. best practice yang saya peroleh sampai saat ini adalah try catch.
Pe
> --> really ? ini best practice belajar sendiri atau ada yang ngasih
> tahu seperti itu ?
Belajar sendiri. Kalau anda pernah buat aplikasi skala besar dengan banyak
sekali masalah seperti...
- table setting
- file setting
- baca file dalam format A sesuai file-setting-nya lalu parsing ke format
fyi, c# tidak punya checked exception krn ada 2 isu utama: scalability
and versionability
berikut wwncara antara Bruce Eckel & Anders Hejlsberg
http://www.artima.com/intv/handcuffs.html
--
regards,
-nasrul
--Menikmati Hidup Mempersembahkan yang Terbaik (Nashroulloh)--
In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote:
"Programmers waste enormous amounts of time thinking about, or worrying about,
the speed of noncritical parts of their programs, and these attempts at
efficiency actually have a strong negative impact when debugging an
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, Daniel Baktiar wrote:
>
> sebaiknya pakai if else, kalau tidak salah exception handling jauh (beberapa
> puluh at
Null Pointer atau LazyException?? hayooo??
Kalo di liat dari contoh codingnya seh kemungkinan besar itu Kayanya
LazyException..
Bener kata om onsir, if else itu beda dengan try catch.. satu buat
condition, satu lagi buat error management.
Ngomong masalah performance ga bisa di ukur sama begituan
2009/9/2 jancrot :
>
>
>> Inti pertanyaan saya lebih efesien dan lebih cepat mana antara cara 1
>> (if else) ataukah cara 2 (try catch) ?
>>
>
> Kalo efisien mungkin lebih baik if else. (Mungkin lho ya..). Detail pastinya
> saya belum pernah buktiin.
>
> Tapi.. best practice yang saya peroleh sampa
@Yudhi
Mmg ada kaitan dengan LazyLoader :p
Cuma penasaran aja sih pengen tau lebih efesien yg mana. Soalnya gerah
juga liat if else banyak banget.
@xsalefter
Tujuannya sama cuma mau ngeset object.
Cara 1 if else nya itu cuma utk mencegah null pointer aja. Tujuan
akhirnya cuma emp.getDepartment.set
2009/9/2 Harry Christian :
>
> @jancrot
> Saya sebenarnya mengharapkan jawaban try catch lebih efesien. Cuma
> baru kamu yang bilang begitu lol. Karena saya sependapat dengan alasan
> yang kamu bilang. If else nya banyak banget blm lagi kalo muncul if
> else baru lagi.
>
> @abangkis
> Ada kemungkin
Kalo urusannya dengan file, I/O, thread memang try/catch menjadi
keharusan. Alasannya karena kesalahan bisa terjadi di luar kontrol
program kita, makanya namanya exception control, bukan flow control.
Dari segi performance jelas if-then-else cuma butuh waktu 1 processor
cycle untuk pindah dari satu
Exception processing mestinya emang lebih lambat, soalnya perlu proses
stacktracenya buat disertakan bersama Exceptionnya...
Tapi berapa x lambatnya gw nggak yakin hehe...
-Kurniady
2009/9/2 xsalefter
>
>
> Afaik, dulu pernah ada dosen gw yang bilang kalo try-catch itu 10x lebih
> lambat daripa
Hi, sorry, ini efek ngikutin thread di tengah-tengah :)
setelah baca mail ini, refer ke mail aslinya, ternyata hal yang saya
omongin intinya sama. Untuk kasus yang di tulis harry best practicenya
memang pake try catch.
So, i stand corrected.
Cheers,
Abangkis
2009/9/2 jancrot :
>
>
>> --> reall
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
in_harmonia wrote:
Sori agak OOT, tapi terlepas dari good practice atau bukan, bukannya Java punya
checked exception yang artinya "pengecualian yang diharapkan"
Me:
Gimana kalau diganti jadi "pengecualian yang telah diprediksi dan diantisipasi
sejak awal"? :D
Powered by Telkomsel BlackBerry®
Pemilihan if-else atau try-catch seharusnya bukan berdasarkan kriteria
performance.
Tapi lebih ke business case dan programming contract.
Checked exception (oleh karena itu harus di catch atau throws)
digunakan untuk 'memaksa' pemanggilnya menghandle error tsb.
Saya biasa pakai seperti ini
publ
jujur aja penggunaan try-catch menurut g adalah topik yang cukup
advance. sampai sekarang g blom ketemu pattern yg bener2 klop banget
untuk masalah try-catch ini.
idealnya menurut g exception handling itu ditujukan untuk mendukung
OOP dalam memodelkan real world scenario. tapi karena pattern tiap
2009/9/9 Jecki :
>
> ada yang bisa share lebih lanjut? mungkin kita bisa bahas di sini:
> 1. checked exception vs unchecked exception (kriteria pemilihan tipe
> exception yang harus di-throw)
Secara umum, checked exception digunakan untuk exception yang bisa
di-catch secara reasonable.
Misalnya, A
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
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
EntityRe
this is assuming that what i wrote is a 'premature optimization' which is
incorrect.
using if-else block is a language construct. the compiler will optimize it
according to its (compiler's) discretion. the jvm will optimize it according
to its (jvm's) discretion.
using try-catch block, by law, req
22 matches
Mail list logo
