Mengapa Sesetengah Pembangun Menentang Pengecualian yang Diperiksa di Java?

Bantahan terhadap pengecualian yang diperiksa

Selama bertahun-tahun saya tidak dapat jawapan yang baik untuk soalan: Mengapakah sesetengah pembangun sangat menentang diperiksa tidak normal? Saya telah mengadakan berbilang perbualan, membaca catatan blog dan membaca perspektif Bruce Eckel (dia adalah orang pertama yang pernah saya lihat bersuara menentang perkara ini).

Saya sedang menulis beberapa kod baharu dan sangat berhati-hati tentang cara saya mengendalikan pengecualian. Saya cuba memahami perspektif orang ramai "kami tidak suka pengecualian yang diperiksa", tetapi saya masih tidak dapat memahaminya.

Setiap perbualan saya telah berakhir dengan soalan yang sama tanpa jawapan... Biar saya sediakan ini:

Secara amnya (dengan reka bentuk Java),

• Ralat untuk perkara yang tidak sepatutnya ditangkap (VM ​​alah kepada kacang tanah dan seseorang menuang balang kacang ke atasnya)
• RuntimeException Digunakan untuk perkara yang salah pengaturcara (pengaturcara berjalan keluar dari hujung tatasusunan)
• Pengecualian (kecuali RuntimeException) digunakan untuk perkara yang tidak dapat dikawal oleh pengaturcara (cakera penuh semasa menulis ke sistem fail, pemegang fail proses Had dicapai, tiada lagi fail boleh dibuka)
• Throwable hanyalah kelas induk bagi semua jenis pengecualian.

Pernyataan yang sering saya dengar ialah jika pengecualian berlaku, apa yang boleh dilakukan oleh pembangun ialah keluar dari program.

Satu lagi hujah biasa yang saya dengar ialah pengecualian yang disemak menjadikannya lebih sukar untuk memfaktorkan semula kod.

Bagi hujah "Saya baru sahaja berhenti", apa yang saya katakan ialah walaupun anda berhenti, anda perlu menunjukkan mesej ralat yang munasabah. Jika anda hanya mengelak daripada mengendalikan ralat, pengguna anda tidak akan terlalu gembira apabila program berhenti tanpa petunjuk yang jelas tentang sebabnya.

Bagi orang ramai yang "menyukarkan pemfaktoran semula", ini menunjukkan bahawa tahap abstraksi yang sesuai tidak dipilih. Daripada mengisytiharkan bahawa kaedah membuang IOException, IOException harus ditukar menjadi pengecualian yang lebih sesuai untuk apa yang berlaku.

Saya tiada masalah membungkus Utama dengan tangkapan(Pengecualian) (atau dalam sesetengah kes tangkap(Boleh Lempar) untuk memastikan program keluar dengan anggun - Tetapi saya sentiasa menangkap pengecualian khusus yang perlu saya tangkap sekurang-kurangnya membolehkan saya memaparkan mesej ralat yang betul

Soalan yang tidak pernah dijawab oleh orang ialah:

>

Jika anda membuang RuntimeException
subkelas sebaliknya Pengecualian
subkelas, jadi bagaimana anda tahu
apa yang anda patut tangkap?

Jika jawapannya ialah untuk menangkap Pengecualian, maka anda juga Itu nampaknya salah bagi saya

jika anda mengendalikan pengecualian sistem dengan cara yang sama. Boleh dibuang, maka anda mengendalikan pengecualian sistem dan ralat VM (dan seumpamanya) dengan cara yang sama itu nampaknya salah kepada saya

Jika jawapannya ialah anda hanya menangkap pengecualian yang anda tahu bagaimana untuk mengetahui pengecualian telah dilemparkan? Apa yang berlaku apabila pengaturcara X melemparkan pengecualian baharu dan terlupa untuk menangkapnya. Itu kelihatan berbahaya kepada saya

.

Saya akan mengatakan bahawa program yang menunjukkan surih tindanan adalah salah. Tidakkah orang yang tidak menyukai pengecualian yang disemak berfikir begitu?

Jadi jika anda tidak menyukai pengecualian yang disemak, bolehkah anda jelaskan mengapa? Dan jawab soalan yang tidak terjawab itu?

Saya tidak mencari nasihat tentang menggunakan mana-mana model, saya sedang mencari sebab mengapa orang melanjutkan daripada RuntimeException dan bukannya dari Exception, dan mengapa mereka menangkap pengecualian dan kemudian membuang semula satu Daripada menambah lontaran RuntimeException pada kaedah mereka. Saya ingin memahami motivasi untuk tidak menyukai pengecualian yang diperiksa.

Atas ialah kandungan terperinci Mengapa Sesetengah Pembangun Menentang Pengecualian yang Diperiksa di Java?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!