Di Jawa, untuk apa pengecualian diperiksa? [Tutup]


14

Pengecualian Java diperiksa telah mendapat beberapa pers yang buruk selama bertahun-tahun. Pertanda jitu adalah bahwa itu adalah satu-satunya bahasa di dunia yang memilikinya (bahkan bahasa JVM lainnya seperti Groovy dan Scala). Pustaka Java yang terkenal seperti Spring dan Hibernate juga tidak menggunakannya.

Saya pribadi telah menemukan satu kegunaan untuk mereka ( dalam logika bisnis antar lapisan), tetapi selain itu saya pengecualian cukup anti-diperiksa.

Apakah ada kegunaan lain yang tidak saya sadari?


Semua perpustakaan inti Java menggunakan pengecualian yang diperiksa cukup luas.
Joonas Pulakka

3
@Joonas aku tahu, dan itu menyebalkan!
Brad Cupit

Jawaban:


22

Pertama-tama, seperti paradigma pemrograman lainnya, Anda perlu melakukannya dengan benar agar bisa berfungsi dengan baik.

Bagi saya keuntungan dari pengecualian yang diperiksa adalah bahwa penulis perpustakaan Java runtime SUDAH telah memutuskan untuk saya masalah umum apa yang mungkin dapat saya tangani secara wajar pada titik panggilan (sebagai lawan dari print-catch tingkat atas). mati blok) dan pertimbangkan sedini mungkin bagaimana menangani masalah ini.

Saya suka mengecek pengecualian karena mereka membuat kode saya lebih kuat dengan memaksa saya untuk berpikir tentang pemulihan kesalahan sedini mungkin.

Lebih tepatnya, bagi saya ini membuat kode saya lebih kuat karena memaksa saya untuk mempertimbangkan kasus sudut aneh sangat awal dalam proses yang bertentangan dengan mengatakan "Ups, kode saya tidak menangani jika file belum ada" berdasarkan kesalahan dalam produksi, yang kemudian harus Anda ulang kode Anda untuk menangani. Menambahkan penanganan kesalahan ke kode yang ada bisa menjadi tugas yang tidak sepele - dan karenanya mahal - ketika mencapai pemeliharaan dan bukan hanya melakukannya sejak awal.

Mungkin file yang hilang adalah hal yang fatal dan harus menyebabkan program crash, tetapi kemudian Anda membuat keputusan dengan

} catch (FileNotFoundException e) {
  throw new RuntimeException("Important file not present", e);
}

Ini juga menunjukkan efek samping yang sangat penting. Jika Anda membungkus pengecualian, Anda dapat menambahkan penjelasan yang masuk dalam tumpukan jejak ! Ini sangat kuat karena Anda dapat menambahkan informasi tentang mis. Nama file yang hilang, atau parameter yang diteruskan ke metode ini atau informasi diagnostik lainnya, dan informasi itu ada tepat di jejak tumpukan yang sering merupakan satu-satunya hal yang Anda dapatkan ketika sebuah program macet.

Orang-orang mungkin mengatakan "kita bisa menjalankan ini di debugger untuk mereproduksi", tetapi saya telah menemukan bahwa kesalahan produksi yang sangat sering tidak dapat direproduksi nanti, dan kami tidak dapat menjalankan debugger dalam produksi kecuali untuk kasus-kasus yang sangat buruk di mana pada dasarnya pekerjaan Anda dipertaruhkan.

Semakin banyak informasi dalam jejak tumpukan Anda, semakin baik. Pengecualian diperiksa membantu saya mendapatkan informasi itu di sana, dan lebih awal.


EDIT: Ini berlaku untuk perancang perpustakaan juga. Satu perpustakaan yang saya gunakan setiap hari berisi banyak, banyak pengecualian yang diperiksa yang bisa dirancang jauh lebih baik sehingga tidak terlalu membosankan untuk digunakan.


+1. Desainer Spring melakukan pekerjaan yang baik dalam menerjemahkan banyak pengecualian Hibernate menjadi pengecualian yang tidak dicentang.
Fil

FYI: Frank Sommers menyebutkan di utas ini bahwa perangkat lunak yang toleran kerap bergantung pada mekanisme yang sama. Mungkin Anda dapat membagi jawaban Anda ke dalam kasus yang dapat dipulihkan dan yang fatal.
rwong

@rwong, bisakah Anda menjelaskan dengan lebih terperinci apa yang ada dalam pikiran Anda?

11

Anda punya dua jawaban bagus yang menjelaskan apa yang sudah menjadi pengecualian dalam praktik. (+1 untuk keduanya.) Tetapi akan bermanfaat untuk memeriksa apa yang dimaksudkan dalam teori, karena niat sebenarnya bermanfaat.

Pengecualian yang diperiksa sebenarnya dimaksudkan untuk membuat bahasa lebih aman. Pertimbangkan metode sederhana seperti perkalian integer. Anda mungkin berpikir bahwa tipe hasil dari metode ini adalah bilangan bulat, tetapi, sebenarnya, hasilnya adalah bilangan bulat atau pengecualian melimpah. Mempertimbangkan hasil integer dengan sendirinya karena tipe kembalinya metode tidak mengekspresikan rentang fungsi yang lengkap.

Dilihat dari sudut ini, tidak sepenuhnya benar untuk mengatakan bahwa pengecualian yang diperiksa belum menemukan jalan mereka ke bahasa lain. Mereka tidak mengambil bentuk yang digunakan Java. Dalam aplikasi Haskell, adalah umum untuk menggunakan tipe data aljabar untuk membedakan antara penyelesaian fungsi yang berhasil dan yang tidak berhasil. Meskipun ini bukan pengecualian, namun, tujuannya sangat mirip dengan pengecualian yang diperiksa; itu adalah API yang dirancang untuk memaksa konsumen API untuk menangani keduanya yang berhasil dalam kasus yang tidak berhasil, misalnya:

data Foo a =
     Success a
   | DidNotWorkBecauseOfA
   | DidNotWorkBecauseOfB

Ini memberi tahu programmer bahwa fungsi tersebut memiliki dua kemungkinan hasil tambahan selain keberhasilan.


+1 untuk pengecualian yang diperiksa tentang keamanan jenis. Saya belum pernah mendengar ide itu sebelumnya, tetapi itu sangat masuk akal.
Ixrec

11

IMO, pengecualian yang diperiksa adalah implementasi yang cacat dari apa yang mungkin merupakan ide yang cukup baik (dalam keadaan yang sama sekali berbeda - tetapi sebenarnya bukan ide yang baik di bawah situasi saat ini).

Ide yang bagus adalah akan lebih baik jika kompiler memverifikasi bahwa semua pengecualian yang berpotensi dibuang oleh suatu program akan tertangkap. Implementasi yang cacat adalah untuk melakukan itu, Java memaksa Anda untuk menangani pengecualian secara langsung di kelas apa pun yang memanggil apa pun yang dinyatakan untuk melemparkan pengecualian yang diperiksa. Salah satu ide paling mendasar (dan keuntungan) dari penanganan pengecualian adalah bahwa jika terjadi kesalahan, ini memungkinkan lapisan kode menengah yang tidak ada hubungannya dengan kesalahan tertentu, untuk sepenuhnya mengabaikan keberadaannya. Pengecualian yang diperiksa (seperti yang diterapkan di Jawa) tidak memungkinkan, sehingga menghancurkan keuntungan utama (utama?) Dari penanganan pengecualian untuk memulai.

Secara teori, mereka bisa membuat pengecualian yang diperiksa bermanfaat dengan menegakkannya hanya berdasarkan program-lebar - yaitu, sambil "membangun" program, membangun pohon dari semua jalur kontrol dalam program. Berbagai simpul di pohon akan diberi penjelasan dengan 1) pengecualian yang dapat mereka hasilkan, dan 2) pengecualian yang dapat mereka tangkap. Untuk memastikan programnya benar, Anda kemudian akan berjalan di pohon, memverifikasi bahwa setiap pengecualian yang dilemparkan pada tingkat mana pun di pohon itu ditangkap pada tingkat yang lebih tinggi di pohon.

Alasan mereka tidak melakukan itu (saya kira, bagaimanapun juga) adalah melakukan hal itu akan sangat sulit - pada kenyataannya, saya ragu ada orang yang menulis sistem build yang dapat melakukan itu untuk apa pun kecuali sangat sederhana (berbatasan dengan "mainan" ") bahasa / sistem. Untuk Java, hal-hal seperti pemuatan kelas dinamis menjadikannya lebih sulit daripada dalam banyak kasus lainnya. Lebih buruk lagi, (tidak seperti sesuatu seperti C) Java tidak (setidaknya biasanya) secara statis dikompilasi / dihubungkan ke executable. Itu berarti tidak ada dalam sistem yang benar-benar memiliki kesadaran global untuk bahkan mencoba melakukan penegakan semacam ini sampai pengguna akhir benar-benar mulai memuat program untuk menjalankannya.

Melakukan penegakan hukum pada saat itu tidak praktis karena beberapa alasan. Pertama-tama, bahkan paling banter itu akan memperpanjang waktu startup, yang sudah menjadi salah satu keluhan terbesar dan paling umum tentang Java. Kedua, untuk melakukan banyak hal baik, Anda benar-benar perlu mendeteksi masalah cukup awal untuk diperbaiki oleh seorang programmer. Ketika pengguna memuat program, sudah terlambat untuk melakukan banyak hal baik - satu-satunya pilihan Anda pada saat itu adalah mengabaikan masalah, atau menolak memuat / menjalankan program sama sekali, jika ada kemungkinan ada pengecualian itu tidak tertangkap.

Karena itu, pengecualian yang diperiksa lebih buruk daripada tidak berguna, tetapi desain alternatif untuk pengecualian yang diperiksa bahkan lebih buruk. Sedangkan ide dasar untuk pengecualian diperiksa tampaknya seperti yang baik, itu benar-benar tidak sangat baik, dan terjadi menjadi sangat cocok miskin untuk Java. Untuk sesuatu seperti C ++, yang biasanya dikompilasi / ditautkan ke dalam executable yang lengkap dengan tidak banyak seperti pemuatan kelas refleksi / dinamis, Anda akan memiliki peluang lebih kecil (walaupun, terus terang, bahkan kemudian menegakkannya dengan benar tanpa jenis kekacauan yang sama seperti yang mereka lakukan). saat ini penyebab di Jawa mungkin masih berada di luar keadaan terkini).


Pernyataan awal pertama Anda tentang harus menangani pengecualian secara langsung sudah salah; Anda cukup menambahkan pernyataan melempar, dan pernyataan melempar mungkin dari tipe induk. Selain itu, jika Anda benar-benar tidak berpikir Anda harus menanganinya, Anda bisa mengubahnya menjadi RuntimeException saja. IDE biasanya membantu Anda dengan kedua tugas.
Maarten Bodewes

2
@owlstead: Terima kasih - Saya mungkin seharusnya lebih berhati-hati dengan kata-kata di sana. Intinya tidak terlalu banyak sehingga Anda benar-benar harus menangkap pengecualian karena setiap tingkat menengah kode perlu menyadari setiap pengecualian yang mungkin mengalir melaluinya. Adapun sisanya: memiliki alat yang membuatnya cepat dan mudah membuat kekacauan kode Anda tidak mengubah fakta bahwa itu membuat kekacauan kode.
Jerry Coffin

Pengecualian diperiksa untuk kontinjensi - hasil yang dapat diprediksi & dipulihkan selain keberhasilan, berbeda dari kegagalan - masalah tingkat rendah / atau sistem yang tidak dapat diprediksi. FileNotFound atau kesalahan membuka koneksi JDBC keduanya dianggap sebagai kemungkinan. Sayangnya, perancang perpustakaan Java membuat kesalahan total & menugaskan semua pengecualian IO dan SQL lainnya ke kelas 'diperiksa' juga; meskipun ini hampir sepenuhnya tidak dapat dipulihkan. literatejava.com/exceptions/…
Thomas W

@owlstead: Pengecualian yang dicentang hanya akan menggelembung melalui lapisan perantara dari tumpukan panggilan jika mereka dilemparkan dalam kasus yang diharapkan oleh kode panggilan perantara . IMHO, pengecualian yang diperiksa akan menjadi hal yang baik jika penelepon harus menangkap mereka atau menunjukkan apakah mereka diharapkan atau tidak ; pengecualian yang tidak terduga harus secara otomatis dibungkus dengan UnexpectedExceptionjenis yang berasal dari RuntimeException. Perhatikan bahwa "melempar" dan "tidak berharap" tidak bertentangan; jika foomelempar BozExceptiondan menelepon bar, itu tidak berarti ia berharap baruntuk melempar BozException.
supercat

10

Mereka benar-benar bagus untuk programmer yang mengganggu dan mendorong pengecualian menelan. Setengah poin dari pengecualian adalah agar Anda memiliki cara standar yang waras untuk menangani kesalahan dan tidak harus berpikir tentang menyebarkan kondisi kesalahan yang tidak dapat Anda tangani secara eksplisit. (Default waras adalah bahwa jika Anda tidak pernah menangani kesalahan di mana pun dalam kode Anda, Anda telah secara efektif menyatakan bahwa hal itu tidak dapat terjadi, dan dibiarkan dengan keluar yang waras dan jejak tumpukan jika Anda salah.) Pengecualian pengecualian dikalahkan ini. Mereka merasa seperti harus secara eksplisit menyebarkan kesalahan dalam C.


4
Mudah memperbaiki: throws FileNotFoundException. Hard fix:catch (FileNotFoundException e) { throw RuntimeException(e); }
Thomas Eding

5

Saya pikir adil untuk mengatakan bahwa pengecualian yang dicek adalah sedikit percobaan yang gagal. Di mana mereka salah adalah bahwa mereka melanggar layering:

  • Modul A dapat dibangun di atas Modul B, di mana
  • Modul B dapat dibangun di atas Modul C.
  • Modul C mungkin tahu cara mengidentifikasi kesalahan, dan
  • Modul A mungkin tahu cara menangani kesalahan.

Pemisahan yang baik dari yang bersangkutan rusak, karena sekarang pengetahuan tentang kesalahan yang bisa saja terbatas pada A dan C sekarang harus tersebar di atas B.

Ada diskusi yang bagus pengecualian yang diperiksa di Wikipedia.

Dan Bruce Eckel juga memiliki artikel yang bagus . Berikut ini kutipannya:

Semakin banyak aturan acak yang Anda tumpukan ke programmer, aturan yang tidak ada hubungannya dengan menyelesaikan masalah yang dihadapi, semakin lambat yang bisa dihasilkan oleh programmer. Dan ini tampaknya bukan faktor linier, tetapi faktor eksponensial

Saya percaya untuk kasus C ++, jika semua metode memiliki throwsklausa spesifikasi, maka Anda dapat memiliki beberapa optimasi yang bagus. Saya tidak percaya Java bisa memiliki kelebihan itu, karena RuntimeExceptionstidak diperiksa. JIT modern harus dapat mengoptimalkan kode dengan baik.

Salah satu fitur bagus dari AspectJ adalah pelunakan pengecualian: Anda dapat mengubah pengecualian yang dicentang menjadi pengecualian yang tidak dicentang, khususnya untuk meningkatkan pelapisan.

Mungkin ironis bahwa Jawa mengalami semua masalah ini, padahal seharusnya bisa diperiksa null, yang mungkin jauh lebih berharga .


haha, tidak pernah berpikir tentang memeriksa hal nol sebagai keputusan yang tidak mereka buat ... Tapi akhirnya saya mengerti bahwa BUKAN masalah bawaan setelah bekerja di Objective-C, yang memungkinkan nulls memiliki metode yang dipanggil.
Dan Rosenstark

3
null-checking adalah rasa sakit yang jauh lebih besar - Anda SELALU harus memeriksa - plus itu tidak memberi tahu alasan mengapa, yang pengecualian yang disebutkan dengan baik tidak.

5

Saya suka pengecualian.

Saya, bagaimanapun, terus-menerus bingung oleh penyalahgunaan mereka.

  1. Jangan menggunakannya untuk penanganan aliran. Anda tidak ingin kode yang mencoba melakukan sesuatu dan menggunakan pengecualian sebagai pemicu untuk melakukan sesuatu yang lain sebagai gantinya karena Pengecualian adalah objek yang perlu dibuat dan menggunakan memori dll. Hanya karena Anda tidak dapat diganggu untuk menulis beberapa jenis if () periksa sebelum Anda melakukan panggilan. Itu hanya malas dan memberi Exception yang mulia nama yang buruk.

  2. Jangan menelan mereka. Pernah. Dalam keadaan apapun. Sebagai minimum absolut Anda menempelkan sesuatu di file log Anda untuk menunjukkan bahwa Pengecualian terjadi. Mencoba melacak jalan Anda melalui kode yang menelan pengecualian adalah mimpi buruk. Sekali lagi, kutuk kalian para penelepon-terkecuali karena telah membuat Pengecualian yang perkasa menjadi jelek!

  3. Perlakukan Pengecualian dengan topi OO Anda aktif. Buat objek Pengecualian Anda sendiri dengan hierarki yang berarti. Laporkan logika bisnis Anda dan pengecualian Anda bersama-sama. Saya biasanya menemukan bahwa jika saya mulai pada area baru dari suatu sistem saya akan menemukan kebutuhan untuk subkelas Pengecualian dalam setengah jam pengkodean jadi hari ini saya mulai dengan menulis kelas Pengecualian.

  4. Jika Anda menulis bit kode 'frameworky', pastikan semua antarmuka awal Anda ditulis untuk membuang Pengecualian baru Anda di tempat yang sesuai ... dan pastikan coders Anda memiliki beberapa kode sampel di sekitar tempat yang harus dilakukan ketika kode mereka melempar IOException tetapi antarmuka yang mereka tulis ingin melemparkan 'ReportingApplicationException'.

Setelah Anda memahami cara membuat Pengecualian bekerja untuk Anda, Anda tidak akan pernah melihat ke belakang.


2
+1 untuk instruksi yang baik. Juga, jika perlu, gunakan initCauseatau inisialisasi pengecualian dengan pengecualian yang menyebabkannya. Contoh: Anda memiliki utilitas I / O yang hanya membutuhkan pengecualian jika penulisan gagal. Namun, ada beberapa alasan mengapa penulisan bisa gagal (tidak bisa mendapatkan akses, kesalahan tulis, dll.) Lempar pengecualian khusus Anda dengan penyebabnya sehingga masalah asli tidak tertelan.
Michael K

3
Saya tidak ingin kasar tetapi apa hubungannya dengan pengecualian CHECKED? :)
palto

Dapat ditulis ulang untuk menulis hierarki pengecualian yang diperiksa sendiri .
Maarten Bodewes

4

Pengecualian yang diperiksa juga dalam ADA.

(Peringatan, posting ini mengandung kepercayaan yang sangat kuat yang mungkin Anda temui).

Pemrogram tidak suka dan mengeluh, atau menulis kode menelan pengecualian.

Pengecualian yang dicentang ada karena hal-hal tidak hanya gagal berfungsi, Anda dapat melakukan analisis mode / efek kegagalan dan menentukan ini terlebih dahulu.

Membaca file bisa gagal. Panggilan RPC bisa gagal. Jaringan IO bisa gagal. Data bisa salah diformat saat diuraikan.

"Jalan bahagia" untuk kode itu mudah.

Saya kenal seseorang di Universitas yang bisa menulis kode "jalan bahagia". Tak satu pun dari kasus tepi yang pernah bekerja. Saat ini ia mengerjakan Python untuk perusahaan sumber terbuka. Kata Nuff.

Jika Anda tidak ingin menangani pengecualian yang dicentang, apa yang sebenarnya Anda katakan adalah

While I'm writing this code, I don't want to consider obvious failure modes.

The User will just have to like the program crashing or doing weird things.

But that's okay with me because 

I'm so much more important than the people who will have to use the software

in the real, messy, error-prone world.

After all, I write the code once, you use it all day long.

Jadi pengecualian yang dicentang tidak akan disukai oleh programmer, karena itu berarti lebih banyak pekerjaan.

Tentu saja, orang lain mungkin menginginkan pekerjaan itu selesai.

Mereka mungkin menginginkan jawaban yang tepat bahkan jika server file gagal / USB stick mati.

Ini adalah kepercayaan aneh dalam komunitas pemrograman bahwa Anda harus menggunakan bahasa pemrograman yang membuat hidup Anda lebih mudah, yang Anda nikmati, ketika pekerjaan Anda adalah menulis perangkat lunak. Pekerjaan Anda adalah memecahkan masalah seseorang, tidak membiarkan Anda terlibat dalam improvisasi Jazz terprogram.

Jika Anda seorang programmer amatir (bukan pemrograman untuk uang), jangan ragu untuk memprogram dalam C # atau bahasa lain tanpa pengecualian. Heck, hentikan perantara dan program di Logo. Anda bisa menggambar pola-pola cantik di lantai dengan kura-kura.


6
Kata-kata kasar bagus Anda sampai di sana.
Adam Lear

2
+1 "Tidak ada kasing tepi yang pernah bekerja. Saat ini dia mengerjakan Python untuk perusahaan sumber terbuka. Nuff berkata." Klasik
NimChimpsky

1
@palto: Java memaksa Anda untuk mempertimbangkan jalur yang tidak mudah. Itulah perbedaan besar. Untuk C #, Anda mungkin berkata, "Pengecualian didokumentasikan" dan cuci tangan Anda. Tetapi programmer lebih rentan terhadap kesalahan. Mereka melupakan banyak hal. Ketika saya menulis kode, saya ingin diingatkan 100% tentang setiap retakan yang dapat diinformasikan oleh kompiler.
Thomas Eding

2
@ThomasEding Java memaksa saya untuk menangani pengecualian di mana metode ini dipanggil. Sangat jarang saya benar-benar ingin melakukan sesuatu tentang hal itu dalam kode panggilan dan biasanya saya ingin menambahkan pengecualian ke lapisan penanganan kesalahan aplikasi saya. Saya kemudian harus memperbaikinya dengan membungkus pengecualian dalam pengecualian Runtime atau saya harus membuat pengecualian saya sendiri. Programmer malas memiliki pilihan ketiga: abaikan saja karena saya tidak peduli. Dengan begitu tidak ada yang tahu kesalahan terjadi dan perangkat lunak memiliki bug yang sangat aneh. Yang ke-3 itu tidak terjadi dengan pengecualian yang tidak dicentang.
palto

3
@ThomasEding Melakukan hal itu akan mengubah antarmuka segala sesuatu di atas yang mengungkapkan detail implementasi yang tidak perlu untuk setiap lapisan aplikasi. Anda hanya dapat melakukan itu jika pengecualian adalah sesuatu yang ingin Anda pulihkan dan masuk akal di antarmuka. Saya tidak ingin menambahkan IOException ke metode getPeople saya karena beberapa file konfigurasi mungkin hilang. Itu tidak masuk akal.
palto

4

Pengecualian yang dicek seharusnya mendorong orang untuk menangani kesalahan dekat dengan sumber yang ada. Semakin jauh dari sumbernya, semakin banyak fungsi telah berakhir di tengah berjalan, dan semakin besar kemungkinan bahwa sistem telah memasuki kondisi yang tidak konsisten. Selain itu, lebih mungkin bahwa Anda menangkap pengecualian yang salah secara tidak sengaja.

Sayangnya, orang cenderung mengabaikan pengecualian atau menambah spesifikasi lemparan yang semakin meningkat. Kedua hal ini melewatkan inti dari apa yang seharusnya dikecualikan dari pengecualian yang diperiksa. Mereka seperti mengubah kode prosedural untuk menggunakan banyak fungsi Getter dan Setter yang seharusnya menjadikannya OO.

Pada dasarnya, pengecualian yang dicentang berusaha membuktikan tingkat kebenaran tertentu dalam kode Anda. Gagasannya hampir sama dengan pengetikan statis, dalam hal ini mencoba untuk membuktikan bahwa hal-hal tertentu benar sebelum kode dijalankan. Masalahnya adalah bahwa semua bukti ekstra itu membutuhkan upaya dan apakah upaya itu berharga?


2
"Mengabaikan pengecualian" seringkali benar - sering kali respons terbaik terhadap pengecualian adalah membiarkan aplikasi mogok. Untuk landasan teoretis dari sudut pandang ini, bacalah Konstruksi Perangkat Berorientasi Objek Bertrand Meyer . Dia menunjukkan bahwa jika pengecualian digunakan dengan benar (untuk pelanggaran kontrak) bahwa pada dasarnya ada dua respons yang benar: (1) biarkan aplikasi crash atau (2) memperbaiki masalah yang menyebabkan pengecualian dan memulai kembali proses. Baca Meyer untuk detailnya; sulit untuk diringkas dalam komentar.
Craig Stuntz

1
@Craig Stuntz, dengan mengabaikan pengecualian yang saya maksud menelan mereka.
Winston Ewert

Ah, itu berbeda. Saya setuju Anda tidak harus menelan mereka.
Craig Stuntz

"Mengabaikan pengecualian seringkali benar - sering kali respons terbaik terhadap pengecualian adalah membiarkan aplikasi macet.": Itu sangat tergantung pada aplikasi. Jika Anda memiliki pengecualian yang tidak tertangkap dalam aplikasi web, hal terburuk yang dapat terjadi adalah bahwa pelanggan Anda akan melaporkan melihat pesan kesalahan pada halaman web, dan Anda dapat menggunakan perbaikan bug dalam beberapa menit. Jika Anda memiliki pengecualian saat pesawat sedang mendarat, Anda sebaiknya menanganinya dan mencoba memulihkannya.
Giorgio

@Iorgio, sangat benar. Meskipun saya bertanya-tanya apakah dalam kasus pesawat atau serupa jika cara terbaik untuk memulihkan adalah dengan reboot sistem.
Winston Ewert
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.