Haruskah seseorang memeriksa nol jika dia tidak mengharapkan nol?

Pekan lalu, kami memiliki argumen panas tentang penanganan null di lapisan layanan aplikasi kami. Pertanyaannya adalah dalam konteks .NET, tetapi akan sama di Jawa dan banyak teknologi lainnya.

Pertanyaannya adalah: apakah Anda harus selalu memeriksa nol dan membuat kode Anda berfungsi apa pun, atau membiarkan pengecualian muncul ketika nol diterima secara tak terduga?

Di satu sisi, memeriksa nol di mana Anda tidak mengharapkannya (yaitu tidak memiliki antarmuka pengguna untuk menanganinya), menurut pendapat saya, sama dengan menulis blok percobaan dengan tangkapan kosong. Anda hanya menyembunyikan kesalahan. Kesalahan mungkin karena ada sesuatu yang berubah dalam kode dan null sekarang merupakan nilai yang diharapkan, atau ada beberapa kesalahan lain dan ID yang salah diteruskan ke metode.

Di sisi lain, memeriksa nol mungkin merupakan kebiasaan yang baik secara umum. Terlebih lagi, jika ada pemeriksaan, aplikasi dapat berfungsi, hanya sebagian kecil dari fungsi yang tidak memiliki efek apa pun. Kemudian pelanggan mungkin melaporkan bug kecil seperti "tidak dapat menghapus komentar" bukannya bug yang lebih parah seperti "tidak dapat membuka halaman X".

Latihan apa yang Anda ikuti dan apa argumen Anda untuk atau menentang salah satu pendekatan?

Memperbarui:

Saya ingin menambahkan beberapa detail tentang kasus khusus kami. Kami mengambil beberapa objek dari database dan melakukan beberapa pemrosesan pada mereka (katakanlah, buat koleksi). Pengembang yang menulis kode tidak mengantisipasi bahwa objek tersebut bisa nol sehingga ia tidak menyertakan pemeriksaan, dan ketika halaman dimuat ada kesalahan dan seluruh halaman tidak memuat.

Jelas, dalam hal ini seharusnya ada cek. Lalu kami masuk ke argumen tentang apakah setiap objek yang diproses harus diperiksa, bahkan jika itu tidak diharapkan akan hilang, dan apakah proses akhirnya harus dibatalkan secara diam-diam.

Manfaat hipotetis adalah bahwa halaman akan terus berfungsi. Pikirkan hasil pencarian di Stack Exchange di berbagai grup (pengguna, komentar, pertanyaan). Metode ini dapat memeriksa nol dan membatalkan pemrosesan pengguna (yang karena bug adalah nol) tetapi mengembalikan bagian "komentar" dan "pertanyaan". Halaman akan terus berfungsi kecuali bahwa bagian "pengguna" akan hilang (yang merupakan bug). Haruskah kita gagal lebih awal dan menghancurkan seluruh halaman atau terus bekerja dan menunggu seseorang memperhatikan bahwa bagian "pengguna" tidak ada?

Pertanyaannya bukanlah seberapa banyak Anda harus memeriksa nullatau membiarkan runtime membuat pengecualian; itu adalah bagaimana Anda harus menanggapi situasi yang tidak terduga seperti itu.

Maka pilihan Anda adalah:

• Lempar pengecualian generik ( NullReferenceException) dan biarkan menggelembung; jika Anda tidak melakukan nullpemeriksaan sendiri, ini yang terjadi secara otomatis.
• Lempar pengecualian khusus yang menjelaskan masalah pada tingkat yang lebih tinggi; ini dapat dicapai baik dengan melemparkan nullcek, atau dengan menangkap NullReferenceExceptiondan melemparkan pengecualian yang lebih spesifik.
• Pulihkan dengan mengganti nilai default yang sesuai.

Tidak ada aturan umum yang mana yang merupakan solusi terbaik. Secara pribadi, saya akan mengatakan:

• Pengecualian umum adalah yang terbaik jika kondisi kesalahan akan menjadi tanda bug serius dalam kode Anda, yaitu, nilai yang nol tidak boleh diizinkan untuk sampai di sana. Pengecualian seperti itu kemudian dapat menggelembungkan semuanya ke dalam kesalahan log apa pun yang telah Anda atur, sehingga seseorang mendapat pemberitahuan dan memperbaiki bug.
• Solusi nilai default baik jika memberikan output semi-berguna lebih penting daripada kebenaran, seperti browser web yang menerima HTML yang secara teknis salah dan melakukan upaya terbaik untuk menjadikannya masuk akal.
• Kalau tidak, saya akan pergi dengan pengecualian khusus dan menanganinya di tempat yang cocok.

IMHO mencoba menangani nilai nol yang tidak Anda harapkan mengarah pada kode yang terlalu rumit. Jika Anda tidak mengharapkan nol, jelaskan dengan melempar ArgumentNullException. Saya benar-benar frustrasi ketika orang memeriksa apakah nilainya nol dan kemudian mencoba menulis beberapa kode yang tidak masuk akal. Hal yang sama berlaku untuk menggunakan SingleOrDefault(atau bahkan lebih buruk mendapatkan koleksi) ketika seseorang benar-benar mengharapkan Singledan banyak kasus lain ketika orang takut (saya tidak benar-benar tahu apa) untuk menyatakan logika mereka dengan jelas.

Kebiasaan memeriksa nullpengalaman saya berasal dari mantan pengembang C atau C ++, dalam bahasa-bahasa tersebut Anda memiliki peluang besar untuk menyembunyikan kesalahan parah ketika tidak memeriksa NULL. Seperti yang Anda ketahui, di Java atau C # hal-hal berbeda, menggunakan null ref tanpa memeriksa nullakan menyebabkan pengecualian, sehingga kesalahan tidak akan disembunyikan secara diam-diam selama Anda tidak mengabaikannya di sisi panggilan. Jadi dalam kebanyakan kasus, memeriksa secara eksplisit nulltidak masuk akal dan membuat kode lebih rumit dari yang diperlukan. Itu sebabnya saya tidak menganggap pemeriksaan nol sebagai kebiasaan yang baik dalam bahasa tersebut (setidaknya, tidak secara umum).

Tentu saja, ada pengecualian dari aturan itu, berikut adalah beberapa yang dapat saya pikirkan:

• Anda menginginkan pesan kesalahan yang lebih baik dan dapat dibaca manusia, memberi tahu pengguna di bagian mana dari program referensi nol yang salah terjadi. Jadi tes Anda untuk null hanya melempar pengecualian yang berbeda, dengan teks kesalahan yang berbeda. Jelas, tidak ada kesalahan yang akan disembunyikan seperti itu.

• Anda ingin membuat program Anda "gagal lebih awal". Misalnya, Anda ingin memeriksa nilai nol dari parameter konstruktor, di mana referensi objek hanya akan disimpan dalam variabel anggota dan digunakan nanti.

• Anda dapat menangani situasi ref null dengan aman, tanpa risiko kesalahan berikutnya, dan tanpa menutupi kesalahan parah.

• Anda ingin jenis pensinyalan kesalahan yang sama sekali berbeda (misalnya, mengembalikan kode kesalahan) dalam konteks Anda saat ini

Gunakan menegaskan untuk menguji dan menunjukkan pra / postconditions dan invarian untuk kode Anda.

Itu membuatnya jauh lebih mudah untuk memahami apa yang diharapkan oleh kode dan apa yang bisa diharapkan untuk ditangani.

Penegasan, IMO, adalah cek yang cocok karena:

• efisien (biasanya tidak digunakan dalam rilis),
• singkat (biasanya satu baris) dan
• jelas (prasyarat dilanggar, ini adalah kesalahan pemrograman).

Saya pikir kode mendokumentasikan diri sendiri adalah penting, oleh karena itu memiliki cek itu baik. Pemrograman defensif, gagal-cepat, membuat pemeliharaan lebih mudah, yang biasanya menghabiskan banyak waktu.

Memperbarui

Mulai elaborasi Anda. Biasanya baik untuk memberikan pengguna akhir aplikasi yang bekerja dengan baik di bawah bug, yaitu menunjukkan sebanyak mungkin. Kekokohan itu baik, karena surga hanya tahu apa yang akan hancur pada saat kritis.

Namun, pengembang & penguji harus mengetahui bug ASAP, jadi Anda mungkin menginginkan kerangka kerja logging dengan kail yang dapat menampilkan peringatan kepada pengguna bahwa ada masalah. Lansiran mungkin harus ditampilkan kepada semua pengguna, tetapi mungkin dapat dirancang secara berbeda tergantung pada lingkungan runtime.

Gagal lebih awal, sering gagal. nulladalah salah satu nilai tak terduga terbaik yang dapat Anda peroleh, karena Anda dapat gagal dengan cepat segera setelah Anda mencoba menggunakannya. Nilai tak terduga lainnya tidak mudah dideteksi. Karena nullsecara otomatis gagal untuk Anda setiap kali Anda mencoba menggunakannya, saya akan mengatakan bahwa itu tidak memerlukan pemeriksaan eksplisit.

• Memeriksa nol harus menjadi sifat kedua Anda

• API Anda akan digunakan oleh orang lain dan harapan mereka cenderung berbeda dari Anda

• Tes unit menyeluruh biasanya menyoroti kebutuhan untuk pemeriksaan referensi nol

• Memeriksa nol tidak menyiratkan pernyataan bersyarat. Jika Anda khawatir bahwa pengecekan nol membuat kode Anda lebih mudah dibaca, maka Anda mungkin ingin mempertimbangkan kontrak kode .NET.

• Pertimbangkan untuk menginstal ReSharper (atau yang serupa) untuk mencari kode Anda untuk pemeriksaan referensi nol yang hilang

Saya akan mempertimbangkan pertanyaan dari sudut pandang semantik, yaitu tanyakan pada diri saya apa yang mewakili NULL pointer atau argumen referensi nol.

Jika fungsi atau metode foo () memiliki argumen x tipe T, x dapat berupa wajib atau opsional .

Di C ++ Anda bisa memberikan argumen wajib sebagai

• Nilai, misalnya void foo (T x)
• Referensi, mis. Void foo (T & x).

Dalam kedua kasus, Anda tidak memiliki masalah memeriksa pointer NULL. Jadi, dalam banyak kasus, Anda tidak perlu memeriksa pointer nol sama sekali untuk argumen wajib.

Jika Anda melewatkan argumen opsional , Anda dapat menggunakan pointer dan menggunakan nilai NULL untuk menunjukkan bahwa tidak ada nilai yang diberikan:

void foo(T* x)

Alternatifnya adalah menggunakan smart pointer like

void foo(shared_ptr<T> x)

Dalam kasus ini, Anda mungkin ingin memeriksa pointer dalam kode, karena itu membuat perbedaan untuk metode foo () apakah x berisi nilai atau tidak ada nilai sama sekali.

Kasus ketiga dan terakhir adalah Anda menggunakan pointer untuk argumen wajib . Dalam hal ini, memanggil foo (x) dengan x == NULL adalah kesalahan dan Anda harus memutuskan bagaimana menangani ini (sama dengan indeks di luar batas atau input yang tidak valid):

1. Tanpa centang: jika ada bug, biarkan crash dan berharap bug ini muncul cukup awal (selama pengujian). Jika tidak (jika Anda gagal gagal cukup awal), harap itu tidak akan muncul dalam sistem produksi karena pengalaman pengguna adalah mereka melihat aplikasi mogok.
2. Periksa semua argumen di awal metode dan laporkan argumen NULL yang tidak valid, mis. Lempar pengecualian dari foo () dan biarkan beberapa metode lain menanganinya. Mungkin hal terbaik untuk dilakukan adalah menunjukkan kepada pengguna jendela dialog yang mengatakan bahwa aplikasi telah mengalami kesalahan internal dan akan ditutup.

Terlepas dari cara gagal yang lebih baik (memberikan informasi lebih banyak kepada pengguna), keuntungan dari pendekatan kedua adalah kemungkinan besar bug akan ditemukan: program akan gagal setiap kali metode dipanggil dengan argumen yang salah sedangkan dengan pendekatan 1 bug hanya akan muncul jika pernyataan dereferencing pointer dijalankan (misalnya jika cabang kanan pernyataan if dimasukkan). Jadi pendekatan 2 menawarkan bentuk yang lebih kuat dari "kegagalan awal".

Di Jawa Anda memiliki lebih sedikit pilihan karena semua objek dilewatkan menggunakan referensi yang selalu dapat menjadi nol. Sekali lagi, jika null mewakili nilai NONE dari argumen opsional, maka memeriksa null akan (mungkin) menjadi bagian dari logika implementasi.

Jika nol adalah input yang tidak valid, maka Anda memiliki kesalahan dan saya akan menerapkan pertimbangan serupa untuk kasus pointer C ++. Karena di Java Anda dapat menangkap pengecualian pointer nol, pendekatan 1 di atas setara dengan pendekatan 2 jika metode foo () meringkas semua argumen input di semua jalur eksekusi (yang mungkin sering terjadi untuk metode kecil).

Meringkas

• Baik di C ++ dan Java, memeriksa apakah argumen opsional adalah null adalah bagian dari logika program.
• Dalam C ++, saya akan selalu memeriksa argumen wajib untuk memastikan bahwa pengecualian yang tepat dilemparkan sehingga program dapat menanganinya dengan cara yang kuat.
• Di Java (atau C #), saya akan memeriksa argumen wajib jika ada jalur eksekusi yang tidak akan melempar untuk memiliki bentuk "gagal awal" yang lebih kuat.

SUNTING

Terima kasih kepada Stilgar untuk lebih jelasnya.

Dalam kasus Anda tampaknya Anda memiliki null sebagai hasil dari suatu metode. Sekali lagi, saya pikir Anda harus terlebih dahulu mengklarifikasi (dan memperbaiki) semantik metode Anda sebelum Anda dapat mengambil keputusan.

Jadi, Anda memiliki metode m1 () memanggil metode m2 () dan m2 () mengembalikan referensi (di Jawa) atau pointer (dalam C ++) ke beberapa objek.

Apa itu semantik m2 ()? Haruskah m2 () selalu mengembalikan hasil yang tidak nol? Jika demikian, maka hasil nol adalah kesalahan internal (dalam m2 ()). Jika Anda memeriksa nilai kembali di m1 () Anda dapat memiliki penanganan kesalahan yang lebih kuat. Jika tidak, Anda mungkin akan memiliki pengecualian, cepat atau lambat. Mungkin tidak. Berharap bahwa pengecualian dilemparkan selama pengujian dan tidak setelah penyebaran Pertanyaan : jika m2 () tidak boleh mengembalikan null, mengapa kembali null? Mungkin harusnya melemparkan pengecualian? m2 () mungkin buggy.

Alternatifnya adalah mengembalikan null adalah bagian dari semantik metode m2 (), yaitu memiliki hasil opsional, yang harus didokumentasikan dalam dokumentasi Javadoc dari metode tersebut. Dalam kasus ini, boleh saja memiliki nilai nol. Metode m1 () harus memeriksanya sebagai nilai lain: tidak ada kesalahan di sini, tetapi mungkin memeriksa apakah hasilnya nol hanyalah bagian dari logika program.

Pendekatan umum saya adalah jangan pernah menguji kondisi kesalahan yang Anda tidak tahu bagaimana mengatasinya . Maka pertanyaan yang perlu dijawab dalam setiap contoh spesifik menjadi: dapatkah Anda melakukan sesuatu yang masuk akal di hadapan nilai yang tidak terduga null?

Jika Anda dapat melanjutkan dengan aman dengan mengganti nilai lain (koleksi kosong, katakanlah, atau nilai default atau contoh), maka dengan segala cara melakukannya. Contoh @ Shahbaz dari World of Warcraft menggantikan satu gambar dengan gambar lain termasuk dalam kategori itu; gambar itu sendiri kemungkinan hanya hiasan, dan tidak memiliki dampak fungsional . (Dalam build debug, saya akan menggunakan warna menjerit untuk menarik perhatian pada fakta bahwa substitusi telah terjadi, tetapi itu sangat tergantung pada sifat aplikasi.) Namun, detail log tentang kesalahan, sehingga Anda tahu itu terjadi; jika tidak, Anda akan menyembunyikan kesalahan yang mungkin ingin Anda ketahui. Menyembunyikannya dari pengguna adalah satu hal (sekali lagi, dengan asumsi pemrosesan dapat dilanjutkan dengan aman); menyembunyikannya dari pengembang adalah hal lain.

Jika Anda tidak dapat melanjutkan dengan aman di hadapan nilai nol, maka gagal dengan kesalahan yang masuk akal; secara umum, saya lebih memilih untuk gagal sesegera mungkin ketika jelas bahwa operasi tidak dapat berhasil, yang menyiratkan memeriksa prasyarat. Ada kalanya Anda tidak ingin langsung gagal, tetapi menunda kegagalan selama mungkin; pertimbangan ini muncul misalnya dalam aplikasi yang berhubungan dengan kriptografi, di mana serangan saluran samping mungkin mengungkapkan informasi yang tidak ingin Anda ketahui. Pada akhirnya, biarkan kesalahan muncul hingga beberapa penangan kesalahan umum, yang pada gilirannya mencatat rincian yang relevan dan menampilkan pesan kesalahan yang bagus (betapapun bagusnya) kepada pengguna.

Perlu juga dicatat bahwa respons yang tepat mungkin sangat berbeda antara pengujian / QA / debug builds, dan build produksi / rilis. Dalam debug build, saya akan gagal sejak awal dan sulit dengan pesan kesalahan yang sangat rinci, untuk membuatnya sangat jelas bahwa ada masalah dan memungkinkan post-mortem untuk menentukan apa yang perlu dilakukan untuk memperbaikinya. Membangun produksi, ketika dihadapkan dengan kesalahan yang dapat dipulihkan dengan aman , mungkin harus mendukung pemulihan.

Tentu NULLtidak diharapkan , tetapi selalu ada bug!

Saya percaya Anda harus memeriksa NULLapakah Anda tidak mengharapkannya atau tidak. Biarkan saya memberi Anda contoh (meskipun mereka tidak di Jawa).

• Dalam World of Warcraft, karena bug gambar salah satu pengembang muncul di sebuah kubus untuk banyak objek. Bayangkan jika mesin grafis tidak mengharapkan NULL pointer, akan ada crash, sementara itu berubah menjadi pengalaman yang tidak begitu fatal (bahkan lucu) bagi pengguna. Paling tidak, Anda tidak akan kehilangan koneksi atau tiba-tiba menyimpan poin.

  Ini adalah contoh di mana memeriksa NULL mencegah kerusakan dan kasus ditangani secara diam-diam.

• Bayangkan program teller bank. Antarmuka melakukan pengecekan dan mengirimkan data input ke bagian yang mendasarinya untuk melakukan transfer uang. Jika bagian inti mengharapkan untuk tidak menerima NULL, maka bug di antarmuka dapat menyebabkan masalah dalam transaksi, mungkin sejumlah uang di tengah hilang (atau lebih buruk, digandakan).

  Dengan "masalah" Maksudku crash (seperti dalam crash crash (katakanlah program ini ditulis dalam C ++), bukan pengecualian null pointer). Dalam hal ini, transaksi harus dibatalkan jika NULL ditemukan (yang tentu saja tidak akan mungkin jika Anda tidak memeriksa variabel terhadap NULL!)

Saya yakin Anda mendapatkan idenya.

Memeriksa validitas argumen untuk fungsi Anda tidak mengacaukan kode Anda, karena itu adalah pasangan memeriksa di bagian atas fungsi Anda (tidak menyebar di tengah) dan sangat meningkatkan kekokohan.

Jika Anda harus memilih antara "program memberi tahu pengguna bahwa ia telah gagal dan dengan anggun mati atau gulung balik ke status yang konsisten yang mungkin membuat log kesalahan" dan "Pelanggaran Akses", tidakkah Anda memilih yang pertama? Itu berarti setiap fungsi harus dipersiapkan untuk dipanggil oleh kode buggy daripada mengharapkan semuanya benar, hanya karena bug selalu ada.

Seperti yang ditunjukkan oleh jawaban yang lain. Jika Anda tidak berharap NULL, jelaskan dengan melempar ArgumentNullException. Dalam pandangan saya, ketika Anda men-debug proyek itu membantu Anda untuk menemukan kesalahan dalam logika program Anda lebih cepat.

Jadi, Anda akan merilis perangkat lunak Anda, jika Anda mengembalikan NullRefrencescek itu, Anda tidak kehilangan apa pun pada logika perangkat lunak Anda, itu hanya membuat dua kali lipat memastikan bahwa bug yang parah tidak akan muncul.

Poin lain adalah bahwa jika NULLmemeriksa parameter fungsi, maka Anda dapat memutuskan apakah fungsi itu tempat yang tepat untuk melakukannya atau tidak; jika tidak, temukan semua referensi ke fungsi dan sebelum mengirimkan parameter ke fungsi, tinjau skenario yang mungkin mengarah pada referensi nol.

Setiap nulldalam sistem Anda adalah bom waktu yang menunggu untuk ditemukan. Periksa nullbatas di mana kode Anda berinteraksi dengan kode yang tidak Anda kendalikan, dan larang di nulldalam kode Anda sendiri. Ini membebaskan Anda dari masalah tanpa naif mempercayai kode asing. Gunakan pengecualian atau semacam Maybe/ Nothingsebagai gantinya.

Sementara pengecualian null pointer pada akhirnya akan dibuang, akan sering dibuang jauh dari titik di mana Anda mendapat null pointer. Bantulah diri Anda sendiri dan persingkat waktu yang diperlukan untuk memperbaiki bug dengan setidaknya mencatat fakta bahwa Anda mendapatkan pointer nol sesegera mungkin.

Bahkan jika Anda tidak tahu apa yang harus dilakukan sekarang, masuk log acara akan menghemat waktu Anda nanti. Dan mungkin orang yang mendapatkan tiket akan dapat menggunakan waktu yang dihemat untuk mengetahui respon yang tepat saat itu.

Karena Fail early, fail fastseperti yang dinyatakan oleh @DeadMG (@empi) tidak mungkin karena aplikasi web harus bekerja dengan baik di bawah bug Anda harus menegakkan aturan

tidak terkecuali menangkap tanpa login

jadi Anda sebagai pengembang menyadari masalah potensial dengan memeriksa log.

jika Anda menggunakan kerangka kerja logging seperti log4net atau log4j Anda dapat mengatur output logging khusus tambahan (alias appender) yang mengirimi Anda kesalahan dan kesalahan fatal. jadi Anda tetap mendapat informasi .

[memperbarui]

jika pengguna akhir halaman tidak menyadari kesalahan Anda dapat mengatur appender yang mengirimi Anda kesalahan dan kesalahan fatal Anda tetap mendapat informasi.

jika ok bahwa pengguna akhir halaman melihat pesan kesalahan cryptic Anda dapat mengatur appender yang menempatkan errorlog untuk pengolahan halaman di akhir halaman.

Tidak masalah bagaimana Anda menggunakan pencatatan jika Anda menelan pengecualian, program melanjutkan dengan data yang masuk akal dan menelan tidak lagi diam.

Sudah ada jawaban yang bagus untuk pertanyaan ini, mungkin satu tambahan untuk mereka: Saya lebih suka pernyataan dalam kode saya. Jika kode Anda hanya dapat bekerja dengan objek yang valid, tetapi gagal dengan nol, Anda harus menyatakan pada nilai nol.

Pernyataan dalam situasi seperti ini akan membiarkan unit dan / atau tes integrasi gagal dengan pesan yang tepat, sehingga Anda dapat menyelesaikan masalah dengan cukup cepat sebelum produksi. Jika kesalahan seperti itu menyelinap melalui tes dan pergi ke produksi (di mana pernyataan harus dinonaktifkan) Anda akan menerima NpEx, dan bug yang parah, tetapi itu lebih baik, daripada beberapa bug kecil yang jauh lebih kabur dan muncul di tempat lain di kode, dan akan lebih mahal untuk diperbaiki.

Lebih jauh lagi jika seseorang harus bekerja dengan pernyataan kode Anda memberitahukan kepadanya tentang asumsi Anda yang Anda buat selama mendesain / menulis kode Anda (dalam hal ini: Hei Bung, objek ini harus disajikan!), Yang membuatnya lebih mudah untuk dipertahankan.

Saya biasanya memeriksa nol tetapi saya "menangani" nol yang tidak terduga dengan melemparkan pengecualian yang memberikan sedikit lebih detail tentang di mana nol terjadi.

Sunting: Jika Anda mendapatkan nol ketika Anda tidak mengharapkan ada sesuatu yang salah - program harus mati.

Itu tergantung pada implementasi bahasa pengecualian. Pengecualian memungkinkan Anda mengambil tindakan untuk mencegah kerusakan data atau melepaskan sumber daya secara bersih jika sistem Anda memasuki keadaan atau kondisi yang tidak terduga. Ini berbeda dari penanganan kesalahan yang merupakan kondisi yang dapat Anda antisipasi. Filosofi saya adalah bahwa Anda harus memiliki penanganan perkecil mungkin. Itu kebisingan. Bisakah metode Anda melakukan sesuatu yang masuk akal dengan menangani pengecualian? Bisakah itu pulih? Bisakah itu memperbaiki atau mencegah kerusakan lebih lanjut? Jika Anda hanya akan menangkap pengecualian dan kemudian kembali dari metode atau gagal dengan cara lain yang tidak berbahaya maka benar-benar tidak ada gunanya menangkap pengecualian. Anda hanya akan menambahkan noise dan kompleksitas pada metode Anda, dan Anda mungkin menyembunyikan sumber kesalahan dalam desain Anda. Dalam hal ini saya akan membiarkan kesalahan naik dan ditangkap oleh lingkaran luar. Jika Anda dapat melakukan sesuatu seperti memperbaiki objek atau menandainya rusak atau melepaskan beberapa sumber daya penting seperti file kunci atau dengan menutup soket dengan bersih maka ini adalah penggunaan pengecualian yang baik. Jika Anda benar-benar mengharapkan NULL untuk tampil sering sebagai tepi kasus yang valid maka Anda harus menangani ini dalam aliran logika normal dengan pernyataan if-the-else atau switch-case atau apa pun, tidak dengan penanganan pengecualian. Misalnya, bidang yang dinonaktifkan dalam formulir dapat diatur ke NULL, yang berbeda dari string kosong yang mewakili bidang yang dikosongkan. Ini adalah area di mana Anda harus menggunakan penilaian yang baik dan akal sehat. Saya belum pernah mendengar aturan praktis yang bagus tentang bagaimana menangani masalah ini di setiap situasi. Jika Anda dapat melakukan sesuatu seperti memperbaiki objek atau menandainya rusak atau melepaskan beberapa sumber daya penting seperti file kunci atau dengan menutup soket dengan bersih maka ini adalah penggunaan pengecualian yang baik. Jika Anda benar-benar mengharapkan NULL untuk tampil sering sebagai tepi kasus yang valid maka Anda harus menangani ini dalam aliran logika normal dengan pernyataan if-the-else atau switch-case atau apa pun, tidak dengan penanganan pengecualian. Misalnya, bidang yang dinonaktifkan dalam formulir dapat diatur ke NULL, yang berbeda dari string kosong yang mewakili bidang yang dikosongkan. Ini adalah area di mana Anda harus menggunakan penilaian yang baik dan akal sehat. Saya belum pernah mendengar aturan praktis yang bagus tentang bagaimana menangani masalah ini di setiap situasi. Jika Anda dapat melakukan sesuatu seperti memperbaiki objek atau menandainya rusak atau melepaskan beberapa sumber daya penting seperti file kunci atau dengan menutup soket dengan bersih maka ini adalah penggunaan pengecualian yang baik. Jika Anda benar-benar mengharapkan NULL untuk tampil sering sebagai tepi kasus yang valid maka Anda harus menangani ini dalam aliran logika normal dengan pernyataan if-the-else atau switch-case atau apa pun, tidak dengan penanganan pengecualian. Misalnya, bidang yang dinonaktifkan dalam formulir dapat diatur ke NULL, yang berbeda dari string kosong yang mewakili bidang yang dikosongkan. Ini adalah area di mana Anda harus menggunakan penilaian yang baik dan akal sehat. Saya belum pernah mendengar aturan praktis yang bagus tentang bagaimana menangani masalah ini di setiap situasi.

Java gagal dalam implementasi penanganan pengecualiannya dengan "pengecualian yang diperiksa" di mana setiap pengecualian yang mungkin dimunculkan oleh objek yang digunakan dalam suatu metode harus ditangkap atau dideklarasikan dalam klausa "throws" dari metode tersebut. Ini kebalikan dari C ++ dan Python di mana Anda dapat memilih untuk menangani pengecualian yang Anda inginkan. Di Jawa, jika Anda memodifikasi isi metode untuk memasukkan panggilan yang dapat menimbulkan pengecualian, Anda dihadapkan dengan pilihan menambahkan penanganan eksplisit untuk pengecualian yang mungkin tidak Anda pedulikan sehingga menambah kebisingan dan kerumitan kode Anda, atau Anda harus tambahkan pengecualian itu ke klausa "throws" dari metode yang Anda modifikasi yang tidak hanya menambah noise dan kekacauan tetapi juga mengubah tanda tangan metode Anda. Anda kemudian harus pergi kode modifikasi di mana pun metode Anda digunakan untuk menangani pengecualian baru metode Anda sekarang dapat meningkatkan atau menambahkan pengecualian pada klausa "melempar" metode tersebut sehingga memicu efek domino dari perubahan kode. "Persyaratan Tangkapan atau Tentukan" harus merupakan salah satu aspek yang paling menjengkelkan di Jawa. Pengecualian pengecualian untuk RuntimeExceptions dan rasionalisasi Java resmi untuk kesalahan desain ini adalah lemah.

Paragraf terakhir itu tidak ada hubungannya dengan menjawab pertanyaan Anda. Saya hanya membenci Jawa.

- Nuh