Kesalahan umum dalam penanganan pengecualian

Pengecualian adalah gangguan terhadap aliran normal eksekusi program Java (atau lainnya). Pelanggaran ini dapat terjadi karena pelanggaran akses memori, pembagian dengan nol, masalah inisialisasi, eksekusi instruksi ilegal, atau kesalahan fatal lainnya. Java mampu menangani semua skenario yang tidak diinginkan dengan baik, tetapi ketika pengembang menggunakan fitur Java ini, beberapa masalah mungkin muncul. Pada artikel ini saya tidak akan membahas cara kerja Penanganan Pengecualian di Java. Saya berasumsi bahwa pembaca sudah familiar dengan hierarki pengecualian, pengecualian yang dicentang , pengecualian yang tidak dicentang , dan pengecualian waktu proses . Di sini kita akan membahas kesalahan paling umum yang harus Anda hindari.

Pemangku Kepentingan dalam Pengecualian

Setiap kali thread eksekusi terputus, informasi tentangnya harus dikembalikan ke pelaksana program. Thread ini dapat dimulai dari layar, dari tugas batch, atau dengan cara lain apa pun. Semua pemicu ini menunggu semacam pelanggaran dalam aliran untuk mengirimkan pesan dalam format tertentu. Pemicu berbasis layar dapat dengan lembut memberi tahu kami bahwa ada beberapa masalah teknis dan kami harus menghubungi dukungan untuk mendapatkan bantuan dan saran. Proses batch atau program Java yang berdiri sendiri mungkin mengharapkan laporan kesalahan muncul dalam bentuk semacam log yang sama sekali tidak dapat dipahami oleh pengguna akhir. Namun pebisnis perlu menerima pesan dalam bahasa yang mereka pahami. NullPointerException yang ditakuti di benak pengguna sangat mengganggu. Terkadang kesalahan ini merupakan akibat dari penggunaan program yang salah, namun terkadang merupakan masalah yang memerlukan perbaikan. Pemangku kepentingan penting kedua adalah orang yang harus menangani permasalahan yang ditimbulkan oleh pengecualian. Orang ini tidak dapat mengamati eksekusi sebenarnya dari program ketika pengecualian terjadi. Ini akan bergantung pada dua hal - pertama, informasi yang diberikan oleh pengguna yang mengalami masalah, dan kedua, semacam log yang dihasilkan ketika terjadi pengecualian. Selain itu, orang yang akan menganalisis permasalahan bukanlah orang yang sama yang menulis program, oleh karena itu pengembang program harus memberikan informasi yang cukup untuk analisis. Satu-satunya cara komunikasi antara pengembang program dan debuggernya adalah dengan log. Selain itu, terkadang karena alasan keamanan, log log terkadang tidak berisi semua detail sebenarnya dari eksekusi program ketika pengecualian terjadi. Mari kita lihat kemungkinan kesalahan dalam penanganan pengecualian. Beberapa dari mereka terlihat sangat bodoh, tetapi ada juga orang. yang tidak memperhatikannya hingga kesalahan tersebut menimbulkan masalah.

Blok pengecualian kosong

Ini adalah salah satu kesalahan yang paling tidak diinginkan dalam penanganan pengecualian. Dalam hal ini, pengecualian diabaikan begitu saja. Solusinya hanya berisi baris komentar untuk meninggalkan pengecualian. try{ }catch(SQLException sqe){ // do nothing } Dalam beberapa kasus yang jarang terjadi, seperti pada blok terakhir ketika database dimatikan, pengecualian dapat diberikan. Dalam hal ini mereka dapat diabaikan. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Generalisasi pesan pengecualian salah

Poin ini bersifat subyektif. Setelah mengetahui pengecualian tersebut, Anda dapat melaporkannya kepada pengguna akhir dalam bentuk pesan ramah. Sangat mungkin bahwa rincian pesan asli akan hilang ketika pesan asli diubah menjadi satu pesan umum. Pesan tersebut harus menyampaikan informasi yang tepat kepada pengguna akhir sehingga ketika menghubungi tim dukungan, pengguna hanya perlu masuk ke log yang sesuai untuk memberikan informasi. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } Dalam aplikasi multi-tingkat, setiap lapisan menangkap pengecualian dan memunculkan jenis pengecualian baru. Terkadang sangat diperlukan untuk memberikan pengecualian jenis tertentu: - Lapisan Akses Data -> membuat DataAccessException - Lapisan Implementasi Bisnis -> membuat BusinessException - Lapisan Layanan Aplikasi -> membuat ApplicationServiceException Semuanya tampak logis, bukan? Di sini kita mungkin harus memilih antara ApplicationServiceException dan BusinessException karena keduanya dapat mewakili informasi yang sama. Salah satu konversi pengecualian ini tampaknya tidak diperlukan.

Menghancurkan kelas StackTrace

Selama proses mengubah pengecualian menjadi tipe khusus baru, jejak tumpukan mungkin hilang, membuat pelacakan penyebab sebenarnya dari pengecualian tersebut menjadi mimpi buruk. Dalam kode di bawah ini Anda dapat melihat bagaimana pengecualian baru dilempar tanpa menerima informasi apa pun dari pengecualian asli. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Menimpa alasan pengecualian

Setiap pesan pengecualian berisi informasi tentang alasan pengecualian tersebut. Namun, ketika pengecualian baru dibuat, informasi tentang pengecualian lama mungkin dihapus secara permanen. Ini mirip dengan contoh di atas di mana StackTrace dapat dihapus karena adanya pengecualian baru.

Tidak ada pencarian pengecualian khusus

Terkadang pengembang ingin bermain aman saat menangani pengecualian. Terkadang hal ini mudah dilakukan. Namun menangkap java.lang.Exception alih-alih pengecualian tertentu tidak dapat diterima. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Tangkapan dan lemparan yang tidak perlu

Tangkap pengecualian jika Anda ingin mengonversinya ke tipe lain, atau jika itu membantu Anda menambahkan beberapa informasi ke pesan pengecualian kepada pengguna akhir atau analis. Jika tidak, buang saja mereka lebih jauh di tanda tangan metode (menggunakan lemparan) alih-alih menangkapnya.

Menangkap RuntimeException

Saya akan merekomendasikan untuk menghindari penangkapan RuntimeException. Sebaliknya, lebih baik menangkap pengecualian tertentu dan menanganinya.

Menemukan pengecualian yang tidak dicentang

Ini adalah topik yang kontroversial apakah akan menangkap pengecualian yang tidak dicentang atau tidak. NullPointerException dan ArrayIndexOutOfBound mungkin merupakan contoh terbaik dari pengecualian yang tidak dicentang. Daripada menangkap pengecualian ini, Anda dapat mengubah kode untuk menangani skenario ini. Misalnya, untuk menghindari NullPointerException, untuk memastikan bahwa semua variabel diinisialisasi, untuk menghindari pengecualian ArrayIndexOutOfBound, untuk mendefinisikan array dengan panjang yang benar, dll.

Masalah yang terkait dengan pencatatan pengecualian

Majalah ini akan membantu pihak yang berkepentingan kedua, yaitu orang yang menganalisis masalah. Terkadang pengembang berlebihan dengan file log dan log dibuat di setiap level aplikasi. Log harus mencatat pengecualian pada tingkat terjadinya. Tampaknya optimal untuk menampilkan peringatan bahwa pengecualian telah terjadi, dengan usulan untuk menghentikan atau melanjutkan eksekusi program, dan wajib mencatat pengecualian tersebut di log.

Pengecualian kontrol aliran

Pengecualiannya adalah gangguan pada aliran normal program, yang berarti Anda perlu menghentikan aliran ini dan memberi tahu pengguna akhir tentang hal itu. Jika kita menambahkan pemanggilan metode yang merupakan thread alternatif, ini akan menyebabkan masalah pemeliharaan yang besar. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Penggunaan java.lang.Exception di mana-mana

Juga bukan ide yang baik untuk menggunakan java.lang.Exception di mana pun untuk pengecualian apa pun. Sebaliknya, lebih baik menggunakan pengecualian khusus aplikasi, atau pengecualian Java standar yang paling tepat. Artikel asli: Kesalahan Umum dalam Penanganan Pengecualian Diterjemahkan dan disuarakan oleh: Ve4niY