Joshua Bloch dalam " Java Efektif " mengatakan itu
Gunakan pengecualian yang dicentang untuk kondisi yang dapat dipulihkan dan pengecualian runtime untuk kesalahan pemrograman (Butir 58 dalam edisi kedua)
Mari kita lihat apakah saya mengerti ini dengan benar.
Inilah pemahaman saya tentang pengecualian yang diperiksa:
try{
String userInput = //read in user input
Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
id = 0; //recover the situation by setting the id to 0
}
1. Apakah hal di atas dianggap sebagai pengecualian yang diperiksa?
2. Apakah RuntimeException merupakan pengecualian yang tidak dicentang?
Inilah pemahaman saya tentang pengecualian yang tidak dicentang:
try{
File file = new File("my/file/path");
FileInputStream fis = new FileInputStream(file);
}catch(FileNotFoundException e){
//3. What should I do here?
//Should I "throw new FileNotFoundException("File not found");"?
//Should I log?
//Or should I System.exit(0);?
}
4. Sekarang, bukankah kode di atas juga bisa menjadi pengecualian yang diperiksa? Saya dapat mencoba memulihkan situasi seperti ini? Bisakah saya? (Catatan: pertanyaan ketiga saya ada di dalam di catch
atas)
try{
String filePath = //read in from user input file path
File file = new File(filePath);
FileInputStream fis = new FileInputStream(file);
}catch(FileNotFoundException e){
//Kindly prompt the user an error message
//Somehow ask the user to re-enter the file path.
}
5. Mengapa orang melakukan ini?
public void someMethod throws Exception{
}
Mengapa mereka membiarkan pengecualian muncul? Bukankah penanganan kesalahan lebih cepat lebih baik? Mengapa menggembung?
6. Haruskah saya menggembungkan pengecualian yang tepat atau menyembunyikannya menggunakan Pengecualian?
Di bawah ini adalah bacaan saya
Kapan memilih pengecualian yang dicentang dan tidak dicentang
DataSeries
kelas yang menyimpan data yang selalu harus tetap dalam urutan berdasarkan waktu. Ada metode untuk menambahkan yang baruDataPoint
ke akhir aDataSeries
. Jika semua kode saya berfungsi dengan baik di seluruh proyek,DataPoint
jangan pernah ditambahkan ke bagian akhir yang memiliki tanggal sebelumnya dengan yang sudah ada di bagian akhir. Setiap modul di seluruh proyek dibangun dengan disangkal ini. Namun, saya memeriksa kondisi ini dan melemparkan pengecualian yang tidak dicentang jika itu terjadi. Mengapa? Jika itu terjadi, saya ingin tahu siapa yang melakukan ini dan memperbaikinya.Jawaban:
Banyak orang mengatakan bahwa pengecualian yang diperiksa (yaitu ini yang harus Anda tangkap atau rethrow secara eksplisit) tidak boleh digunakan sama sekali. Mereka dihilangkan dalam C # misalnya, dan sebagian besar bahasa tidak memilikinya. Jadi, Anda selalu dapat melempar subkelas
RuntimeException
(pengecualian yang tidak dicentang)Namun, saya pikir pengecualian yang diperiksa berguna - mereka digunakan ketika Anda ingin memaksa pengguna API Anda untuk berpikir bagaimana menangani situasi yang luar biasa (jika itu dapat dipulihkan). Hanya saja pengecualian yang diperiksa digunakan secara berlebihan di platform Java, yang membuat orang membenci mereka.
Inilah pandangan saya tentang topik ini .
Adapun pertanyaan-pertanyaan khusus:
Apakah
NumberFormatException
mempertimbangkan pengecualian yang diperiksa?Tidak. Tidak
NumberFormatException
dicentang (= subkelas dariRuntimeException
). Mengapa? Saya tidak tahu (tapi seharusnya ada metodeisValidInteger(..)
)Apakah
RuntimeException
pengecualian tidak dicentang?Ya persis.
Apa yang harus saya lakukan di sini?
Tergantung di mana kode ini dan apa yang Anda inginkan terjadi. Jika berada di lapisan UI - tangkap dan tunjukkan peringatan; jika itu ada di lapisan layanan - jangan tangkap sama sekali - biarkan menggelembung. Hanya saja, jangan menelan pengecualian. Jika pengecualian terjadi di sebagian besar kasus, Anda harus memilih salah satu dari ini:
Sekarang, tidak bisakah kode di atas juga merupakan pengecualian yang diperiksa? Saya dapat mencoba memulihkan situasi seperti ini? Bisakah saya?
Itu bisa saja. Tapi tidak ada yang menghentikan Anda untuk menangkap pengecualian yang tidak diperiksa
Mengapa orang menambahkan kelas
Exception
dalam klausa pelemparan?Paling sering karena orang malas untuk mempertimbangkan apa yang harus ditangkap dan apa yang harus dipikirkan kembali. Melempar
Exception
adalah praktik yang buruk dan harus dihindari.Sayangnya, tidak ada aturan tunggal yang memungkinkan Anda menentukan kapan harus menangkap, kapan harus rethrow, kapan harus menggunakan dicentang dan kapan harus menggunakan pengecualian yang tidak dicentang. Saya setuju ini menyebabkan banyak kebingungan dan banyak kode buruk. Prinsip umum dinyatakan oleh Bloch (Anda mengutip sebagian darinya). Dan prinsip umum adalah untuk memikirkan kembali pengecualian pada lapisan di mana Anda bisa menanganinya.
sumber
Apakah sesuatu merupakan "pengecualian yang diperiksa" tidak ada hubungannya dengan apakah Anda menangkapnya atau apa yang Anda lakukan di blok tangkap. Ini properti kelas pengecualian. Apa pun yang merupakan subkelas
Exception
kecuali untukRuntimeException
dan subkelasnya adalah pengecualian yang diperiksa.Kompiler Java memaksa Anda untuk menangkap pengecualian yang dicentang atau mendeklarasikannya dalam tanda tangan metode. Seharusnya meningkatkan keamanan program, tetapi pendapat mayoritas tampaknya tidak sebanding dengan masalah desain yang dibuatnya.
Karena itulah seluruh titik pengecualian. Tanpa kemungkinan ini, Anda tidak perlu pengecualian. Mereka memungkinkan Anda untuk menangani kesalahan pada tingkat yang Anda pilih, alih-alih memaksa Anda untuk menanganinya dalam metode tingkat rendah di mana mereka awalnya terjadi.
sumber
Throwable
: "Throwable dan subclass dari Throwable yang bukan juga subclass dari RuntimeException atau Error dianggap sebagai pengecualian yang dicek"Apakah hal di atas dianggap sebagai pengecualian yang diperiksa? Tidak. Fakta bahwa Anda menangani pengecualian tidak membuatnya menjadi
Checked Exception
jika itu adalahRuntimeException
.Apakah
RuntimeException
ituunchecked exception
? IyaChecked Exceptions
adalahsubclasses
darijava.lang.Exception
Unchecked Exceptions
yangsubclasses
darijava.lang.RuntimeException
Panggilan yang melempar pengecualian yang diperiksa harus dimasukkan dalam blok coba {} atau ditangani pada level di atas dalam pemanggil metode. Dalam hal ini metode saat ini harus menyatakan bahwa ia melempar pengecualian tersebut sehingga penelepon dapat membuat pengaturan yang tepat untuk menangani pengecualian.
Semoga ini membantu.
A: Ya ini pertanyaan yang sangat bagus dan pertimbangan desain yang penting. Pengecualian kelas adalah kelas pengecualian yang sangat umum dan dapat digunakan untuk membungkus pengecualian tingkat rendah internal. Anda akan lebih baik membuat pengecualian khusus dan membungkus di dalamnya. Tapi, dan yang besar - Jangan pernah mengaburkan dalam akar penyebab asli yang mendasarinya. Sebagai contoh,
Don't ever
lakukan hal berikut -Alih-alih lakukan hal berikut:
Menghilangkan akar penyebab asli mengubur penyebab sebenarnya di luar pemulihan adalah mimpi buruk bagi tim dukungan produksi di mana semua mereka diberi akses adalah log aplikasi dan pesan kesalahan. Meskipun yang terakhir adalah desain yang lebih baik tetapi banyak orang tidak menggunakannya sering karena pengembang hanya gagal menyampaikan pesan yang mendasarinya kepada pemanggil. Jadi buatlah catatan tegas:
Always pass on the actual exception
kembali apakah dibungkus dengan aplikasi spesifik atau tidak.RuntimeException
s sebagai aturan umum tidak boleh dicoba. Mereka umumnya menandakan kesalahan pemrograman dan harus dibiarkan sendiri. Sebaliknya programmer harus memeriksa kondisi kesalahan sebelum memohon beberapa kode yang mungkin menghasilkan aRuntimeException
. Misalnya:Ini adalah praktik pemrograman yang buruk. Alih-alih, pemeriksaan nol seharusnya dilakukan seperti -
Tapi ada kalanya pengecekan error semacam itu mahal seperti pemformatan angka, pertimbangkan ini -
Di sini pemeriksaan kesalahan sebelum pemanggilan tidak sepadan dengan usaha karena pada dasarnya berarti menduplikasi semua kode konversi string-ke-integer di dalam metode parseInt () - dan rentan kesalahan jika diterapkan oleh pengembang. Jadi lebih baik untuk menyingkirkan try-catch.
Jadi
NullPointerException
danNumberFormatException
keduanyaRuntimeExceptions
, menangkapNullPointerException
harus diganti dengan cek kosong anggun sementara saya merekomendasikan menangkap secaraNumberFormatException
eksplisit untuk menghindari kemungkinan pengenalan kode rawan kesalahan.sumber
exception
, haruskah saya melembungkan pengecualian yang tepat atau menyembunyikannya menggunakanException
. Saya menulis kode di atas beberapa kode warisan, danException
digelembungkan di semua tempat. Saya ingin tahu apakah ini perilaku yang benar?LoginFailureException(sqle)
?LoginFailureException
meluasException
dan mendeklarasikan konstruktorpublic LoginFailureException(Throwable cause) { super(cause) }
1. Jika Anda tidak yakin tentang pengecualian, periksa API:
2. Ya, dan setiap pengecualian yang memperpanjangnya.
3. Tidak perlu menangkap dan melempar pengecualian yang sama. Anda dapat menampilkan Dialog File baru dalam kasus ini.
4. FileNotFoundException adalah sudah pengecualian diperiksa.
5. Jika diharapkan memanggil metode
someMethod
untuk menangkap pengecualian, yang terakhir dapat dibuang. Itu hanya "mengoper bola". Contoh penggunaannya adalah jika Anda ingin membuangnya dalam metode pribadi Anda sendiri, dan menangani pengecualian dalam metode publik Anda sebagai gantinya.Bacaan yang bagus adalah Oracle doc itu sendiri: http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html
Ada juga sedikit informasi penting dalam Spesifikasi Bahasa Jawa :
Intinya IMHO adalah bahwa Anda dapat menangkap apa pun
RuntimeException
, tetapi Anda tidak diharuskan dan, pada kenyataannya implementasi tidak diperlukan untuk mempertahankan pengecualian yang tidak dicentang yang sama yang dilemparkan, karena itu bukan bagian dari kontrak.sumber
exception
, haruskah saya melembungkan pengecualian yang tepat atau menyembunyikannya menggunakanException
. Saya menulis kode di atas beberapa kode warisan, danException
digelembungkan di semua tempat. Saya ingin tahu apakah ini perilaku yang benar?1) Tidak, NumberFormatException adalah Pengecualian yang tidak dicentang. Meskipun Anda menangkapnya (Anda tidak diharuskan) karena tidak dicentang. Ini karena itu adalah subkelas
IllegalArgumentException
yang merupakan subkelas dariRuntimeException
.2)
RuntimeException
adalah akar dari semua Pengecualian yang tidak dicentang. Setiap subkelas dariRuntimeException
tidak dicentang. Semua Pengecualian lainnya danThrowable
diperiksa kecuali untuk Kesalahan (Yang termasuk dalamThrowable
).3/4) Anda bisa memberi tahu pengguna bahwa mereka memilih file yang tidak ada dan meminta yang baru. Atau hanya berhenti memberi tahu pengguna bahwa mereka memasukkan sesuatu yang tidak valid.
5) Melempar dan menangkap
'Exception'
adalah praktik yang buruk. Tetapi lebih umum, Anda bisa melempar pengecualian lain sehingga penelepon dapat memutuskan bagaimana menghadapinya. Misalnya, jika Anda menulis perpustakaan untuk menangani membaca beberapa input file dan metode Anda melewati file yang tidak ada, Anda tidak tahu bagaimana menanganinya. Apakah penelepon ingin bertanya lagi atau berhenti? Jadi Anda membuang Exception ke rantai kembali ke penelepon.Dalam banyak kasus, suatu
unchecked Exception
terjadi karena programmer tidak memverifikasi input (dalam kasusNumberFormatException
pada pertanyaan pertama Anda). Itu sebabnya opsional untuk menangkap mereka, karena ada cara yang lebih elegan untuk menghindari menghasilkan pengecualian itu.sumber
exception
, haruskah saya melembungkan pengecualian yang tepat atau menyembunyikannya menggunakanException
. Saya menulis kode di atas beberapa kode warisan, danException
digelembungkan di semua tempat. Saya ingin tahu apakah ini perilaku yang benar?Diperiksa - Rawan terjadi. Diperiksa dalam waktu kompilasi.
Mis. Operasi File
Tidak Diperhatikan - Karena data buruk. Diperiksa dalam Run time.
Misalnya..
Di sini pengecualian disebabkan oleh data yang buruk dan tidak dapat ditentukan selama waktu kompilasi.
sumber
Pengecualian yang diperiksa diperiksa pada waktu kompilasi oleh JVM dan terkait dengan sumber daya (file / db / stream / socket dll). Motif dari pengecualian yang diperiksa adalah bahwa pada waktu kompilasi jika sumber daya tidak tersedia, aplikasi harus mendefinisikan perilaku alternatif untuk menangani hal ini di blok tangkapan / akhirnya.
Pengecualian yang tidak dicentang adalah murni kesalahan program, perhitungan yang salah, data nol atau bahkan kegagalan dalam logika bisnis dapat menyebabkan pengecualian runtime. Benar-benar baik untuk menangani / menangkap pengecualian yang tidak dicentang dalam kode.
Penjelasan diambil dari http://coder2design.com/java-interview-questions/
sumber
Deskripsi favorit mutlak saya tentang perbedaan antara pengecualian tidak dicentang dan dicentang disediakan oleh artikel jejak Tutorial Java, " Pengecualian tidak dicentang - Kontroversi " (maaf untuk mendapatkan semua dasar pada posting ini - tapi, hei, dasar-dasarnya kadang-kadang yang terbaik):
Inti dari "apa jenis pengecualian untuk melempar" adalah semantik (sampai taraf tertentu) dan kutipan di atas memberikan dan pedoman yang sangat baik (karenanya, saya masih terpesona oleh gagasan bahwa C # menyingkirkan pengecualian yang diperiksa - khususnya sebagaimana Liskov berpendapat untuk manfaatnya).
Sisanya kemudian menjadi logis: ke pengecualian mana kompilator mengharapkan saya untuk merespons, secara eksplisit? Yang Anda harapkan klien pulih.
sumber
Untuk menjawab pertanyaan terakhir (yang lain tampaknya dijawab dengan tuntas di atas), "Haruskah saya melontarkan pengecualian yang tepat atau menyembunyikannya menggunakan Pengecualian?"
Saya berasumsi Anda bermaksud sesuatu seperti ini:
Tidak, selalu nyatakan pengecualian yang setepat mungkin, atau daftar semacam itu. Pengecualian yang Anda nyatakan metode Anda mampu melempar adalah bagian dari kontrak antara metode Anda dan pemanggil. Melempar
"FileNotFoundException"
berarti ada kemungkinan nama file tidak valid dan file tidak akan ditemukan; penelepon harus menangani hal itu dengan cerdas. MelemparException
berarti "Hei, dia tidak terjadi. Kesepakatan." Yang sangat miskinAPI
.Dalam komentar pada artikel pertama ada beberapa contoh di mana "melempar
Exception
" adalah deklarasi yang sah dan masuk akal, tetapi itu tidak berlaku untuk sebagian besarnormal
kode " " yang akan Anda tulis.sumber
Pengecualian Runtime : Pengecualian runtime disebut sebagai pengecualian yang tidak dicentang. Semua pengecualian lain diperiksa pengecualian, dan mereka tidak berasal dari java.lang.RuntimeException.
Pengecualian yang Dicentang : Pengecualian yang dicentang harus ditangkap di suatu tempat dalam kode Anda. Jika Anda memanggil metode yang melempar pengecualian yang diperiksa tetapi Anda tidak menangkap pengecualian yang dicentang di suatu tempat, kode Anda tidak akan dikompilasi. Itu sebabnya mereka disebut pengecualian diperiksa: kompilator memeriksa untuk memastikan bahwa mereka ditangani atau dideklarasikan.
Sejumlah metode di Java API melempar pengecualian yang diperiksa, jadi Anda akan sering menulis penangan pengecualian untuk mengatasi pengecualian yang dihasilkan oleh metode yang tidak Anda tulis.
sumber
Mengapa mereka membiarkan pengecualian muncul? Bukankah penanganan kesalahan lebih cepat lebih baik? Mengapa menggembung?
Sebagai contoh katakanlah Anda memiliki beberapa aplikasi client-server dan klien telah membuat permintaan untuk beberapa sumber daya yang tidak dapat ditemukan atau untuk sesuatu kesalahan lain beberapa mungkin terjadi di sisi server saat memproses permintaan pengguna maka itu adalah tugas dari server untuk memberi tahu klien mengapa dia tidak bisa mendapatkan hal yang dia minta, jadi untuk mencapai itu di sisi server, kode ditulis untuk melempar pengecualian menggunakan kata kunci throw alih-alih menelan atau menangani itu. jika server menanganinya / menelan itu, maka tidak akan ada kesempatan untuk memberi tahu klien bahwa kesalahan telah terjadi.
Catatan: Untuk memberikan deskripsi yang jelas tentang apa yang telah terjadi jenis kesalahan kita dapat membuat objek Pengecualian kita sendiri dan melemparkannya ke klien.
sumber
Saya pikir pengecualian yang diperiksa adalah pengingat yang baik untuk pengembang yang menggunakan perpustakaan eksternal bahwa ada yang salah dengan kode dari perpustakaan itu dalam situasi luar biasa.
Baca lebih lanjut tentang pengecualian dicentang vs tidak dicentang di sini http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/
sumber
Saya hanya ingin menambahkan beberapa alasan untuk tidak menggunakan pengecualian yang diperiksa sama sekali. Ini bukan jawaban yang lengkap, tetapi saya merasa itu menjawab sebagian dari pertanyaan Anda, dan melengkapi banyak jawaban lainnya.
Setiap kali pengecualian yang diperiksa terlibat, ada suatu
throws CheckedException
tempat di dalam tanda tangan metode (CheckedException
bisa berupa pengecualian yang diperiksa). Tanda tangan TIDAK melemparkan Pengecualian, melemparkan Pengecualian adalah aspek implementasi. Antarmuka, tanda tangan metode, kelas induk, semua hal ini TIDAK harus bergantung pada implementasinya. Penggunaan Pengecualian yang dicentang di sini (sebenarnya fakta bahwa Anda harus mendeklarasikanthrows
dalam tanda tangan metode) mengikat antarmuka tingkat tinggi Anda dengan implementasi antarmuka ini.Mari saya tunjukkan sebuah contoh.
Mari kita memiliki antarmuka yang bagus dan bersih seperti ini
Sekarang kita dapat menulis banyak implementasi metode
foo()
, seperti iniKelas Foo baik-baik saja. Sekarang mari kita membuat upaya pertama di kelas Bar
Bar kelas ini tidak akan dikompilasi. Karena InterruptedException adalah pengecualian yang dicentang, Anda harus menangkapnya (dengan try-catch inside method foo ()) atau menyatakan bahwa Anda membuangnya (menambah
throws InterruptedException
tanda tangan metode). Karena saya tidak ingin menangkap pengecualian ini di sini (saya ingin itu menyebar ke atas sehingga saya bisa menghadapinya dengan benar di tempat lain), mari kita ubah tanda tangan.Bar kelas ini tidak akan dikompilasi juga! Metode bar foo () TIDAK menimpa metode IFoo foo () karena tanda tangannya berbeda. Saya bisa menghapus anotasi @Override, tapi saya ingin memprogram terhadap antarmuka IFoo suka
IFoo foo;
dan nanti memutuskan implementasi yang ingin saya gunakan, sepertifoo = new Bar();
. Jika metode foo Bar () tidak menggantikan metode foo IFoo, ketika saya melakukannyafoo.foo();
tidak akan memanggil implementasi foo () Bar.Untuk membuat Bar
public void foo() throws InterruptedException
menimpa IFoo,public void foo()
saya HARUS menambahkanthrows InterruptedException
ke tanda tangan metode IFoo. Akan tetapi, ini akan menyebabkan masalah dengan kelas Foo saya, karena tanda tangan metode foo () berbeda dari tanda tangan metode IFoo. Selain itu, jika saya menambahkanthrows InterruptedException
ke metode Foo foo () saya akan mendapatkan kesalahan lain yang menyatakan bahwa metode Foo foo () menyatakan bahwa ia melempar InterruptedException namun tidak pernah melempar InterruptedException.Seperti yang Anda lihat (jika saya melakukan pekerjaan yang layak dalam menjelaskan hal ini), fakta bahwa saya melempar pengecualian yang diperiksa seperti InterruptedException memaksa saya untuk mengikat antarmuka IFoo ke salah satu implementasinya, yang pada gilirannya menyebabkan kekacauan pada IFoo implementasi lainnya!
Ini adalah salah satu alasan utama mengapa pengecualian yang diperiksa adalah BURUK. Dalam topi.
Salah satu solusinya adalah menangkap pengecualian yang dicentang, membungkusnya dalam pengecualian yang tidak dicentang, dan membuang pengecualian yang tidak dicentang.
sumber
throws InterruptedException
metode tanda tangan IFoo tanpa membuang apa pun dalam implementasi apa pun. Jadi itu tidak benar-benar menyebabkan masalah. Jika dalam sebuah antarmuka Anda membuat setiap metode tanda tangan lemparException
, itu hanya memberikan implementasi pilihan untuk melempar atau tidak membuang pengecualian (pengecualian apa pun, sepertiException
merangkum semua pengecualian).throw Exception
klausa dalam tanda tangan mereka, meskipun implementasi Anda tidak akan membuang apa pun atau mungkin pengecualian yang lebih spesifik. Tapi saya masih merasa itu adalah praktik yang baik untuk selalu membuang Exception untuk metode Interface karena, sekali lagi, ini memberikan pengguna pilihan untuk melempar atau tidak melempar apa pun.subclasses
dari kelasRuntimeException
adalah pengecualian yang tidak dicentang.Exception
tetapi tidakRuntimeException
dianggapchecked exceptions
.checked exception
.throws
klausa yang berisichecked-exception
.Exception
kelas didefinisikan untuk diperiksa ketika mereka dianggap cukup penting untuk ditangkap atau dideklarasikan.sumber
Berikut adalah aturan sederhana yang dapat membantu Anda memutuskan. Ini terkait dengan bagaimana antarmuka digunakan di Jawa.
Ambil kelas Anda dan bayangkan merancang antarmuka untuk itu sehingga antarmuka menggambarkan fungsionalitas kelas tetapi tidak ada implementasi yang mendasarinya (sebagaimana seharusnya antarmuka). Berpura-puralah mungkin Anda dapat mengimplementasikan kelas dengan cara lain.
Lihatlah metode antarmuka dan pertimbangkan pengecualian yang mungkin mereka keluarkan:
Jika pengecualian dapat dilemparkan oleh suatu metode, terlepas dari implementasi yang mendasarinya (dengan kata lain, itu menggambarkan fungsionalitas saja) maka itu mungkin harus menjadi pengecualian yang diperiksa di antarmuka.
Jika pengecualian disebabkan oleh implementasi yang mendasarinya, seharusnya tidak ada di antarmuka. Oleh karena itu, itu harus berupa pengecualian yang tidak dicentang di kelas Anda (karena pengecualian yang tidak dicentang tidak perlu muncul dalam tanda tangan antarmuka), atau Anda harus membungkusnya dan menyusun kembali sebagai pengecualian yang diperiksa yang merupakan bagian dari metode antarmuka.
Untuk memutuskan apakah Anda harus membungkus dan rethrow, Anda harus mempertimbangkan lagi apakah masuk akal bagi pengguna antarmuka untuk segera menangani kondisi pengecualian, atau pengecualian yang begitu umum sehingga tidak ada yang dapat Anda lakukan tentang hal itu dan harus menyebarkan tumpukan. Apakah pengecualian yang dibungkus masuk akal ketika dinyatakan sebagai fungsionalitas dari antarmuka baru yang Anda tetapkan atau apakah itu hanya pembawa untuk sekumpulan kondisi kesalahan yang mungkin yang juga dapat terjadi pada metode lain? Jika yang pertama, itu mungkin masih merupakan pengecualian yang diperiksa, jika tidak maka harus tidak dicentang.
Anda biasanya tidak boleh merencanakan untuk "melambungkan" pengecualian (catch and rethrow). Entah pengecualian harus ditangani oleh penelepon (dalam hal ini dicek) atau harus naik sepenuhnya ke penangan tingkat tinggi (dalam hal ini paling mudah jika tidak dicentang).
sumber
Hanya untuk menunjukkan bahwa jika Anda melempar pengecualian yang dicentang ke dalam kode dan tangkapannya beberapa tingkat di atas, Anda perlu mendeklarasikan pengecualian dalam tanda tangan setiap metode antara Anda dan tangkapan. Jadi, enkapsulasi rusak karena semua fungsi di jalur lempar harus tahu tentang detail pengecualian itu.
sumber
Singkatnya, pengecualian yang harus ditangani oleh modul atau modul Anda selama runtime disebut pengecualian yang diperiksa; lain pengecualian dicentang yang baik
RuntimeException
atauError
.Dalam video ini, ini menjelaskan pengecualian dicentang dan tidak dicentang di Jawa:
https://www.youtube.com/watch?v=ue2pOqLaArw
sumber
Semua itu diperiksa pengecualian. Pengecualian yang tidak dicentang adalah subclass dari RuntimeException. Keputusannya bukan bagaimana menanganinya, itu harus kode Anda membuangnya. Jika Anda tidak ingin kompiler memberi tahu Anda bahwa Anda belum menangani pengecualian, maka Anda menggunakan pengecualian (subkelas RuntimeException) yang tidak dicentang. Itu harus disimpan untuk situasi yang tidak dapat Anda pulihkan, seperti kehabisan memori kesalahan dan sejenisnya.
sumber
Jika ada yang peduli dengan bukti lain untuk tidak menyukai pengecualian yang diperiksa, lihat beberapa paragraf pertama dari perpustakaan JSON yang populer:
"Meskipun ini merupakan pengecualian yang dicentang, ini jarang dapat dipulihkan. Sebagian besar penelepon hanya harus membungkus pengecualian ini dalam pengecualian yang tidak dicentang dan rethrow:"
Jadi mengapa ada orang yang membuat pengembang terus memeriksa pengecualian, jika kita harus "membungkusnya" saja? lol
http://developer.android.com/reference/org/json/JSONException.html
sumber
Pengecualian yang Diperiksa :
Pengecualian yang diperiksa oleh kompiler untuk kelancaran pelaksanaan program saat runtime disebut Pengecualian yang Diperiksa.
Ini terjadi pada waktu kompilasi.
Semua subclass kelas Exception kecuali RuntimeException adalah Checked Exception.
Contoh Hipotetis - Misalkan Anda meninggalkan rumah untuk ujian, tetapi jika Anda memeriksa apakah Anda mengambil Tiket Hall di rumah (waktu kompilasi) maka tidak akan ada masalah di Ruang Ujian (runtime).
Pengecualian tidak dicentang :
Pengecualian yang tidak diperiksa oleh kompiler disebut Pengecualian Tidak Dicentang.
Ini terjadi saat runtime.
Jika pengecualian ini tidak ditangani dengan benar, mereka tidak memberikan kesalahan waktu kompilasi. Tetapi program ini akan dihentikan sebelum waktunya pada saat runtime.
Semua subclass dari RunTimeException dan Kesalahan adalah pengecualian yang tidak dicentang.
Contoh Hipotetis - Misalkan Anda berada di ruang ujian tetapi entah bagaimana sekolah Anda mengalami kecelakaan kebakaran (berarti saat runtime) di mana Anda tidak dapat melakukan apa pun pada waktu itu tetapi tindakan pencegahan dapat dilakukan sebelumnya (waktu kompilasi).
sumber
Semua pengecualian harus diperiksa pengecualian.
Pengecualian yang tidak dicentang adalah goto yang tidak dibatasi. Dan goto yang tidak terbatas dianggap sebagai hal yang buruk.
Pengecualian yang tidak dicentang merusak enkapsulasi. Untuk memprosesnya dengan benar, semua fungsi di pohon panggilan antara pelempar dan penangkap harus diketahui untuk menghindari bug.
Pengecualian adalah kesalahan dalam fungsi yang melemparnya tetapi bukan kesalahan dalam fungsi yang memprosesnya. Tujuan pengecualian adalah untuk memberikan program kesempatan kedua dengan menunda keputusan apakah itu kesalahan atau tidak untuk konteks lain. Hanya dalam konteks lain keputusan yang tepat dapat dibuat.
sumber