Pengecualian ialah gangguan kepada aliran biasa pelaksanaan program Java (atau mana-mana yang lain). Pelanggaran ini boleh berlaku disebabkan oleh pelanggaran capaian memori, pembahagian dengan sifar, masalah permulaan, pelaksanaan arahan yang menyalahi undang-undang atau sebarang ralat maut yang lain. Java mampu mengendalikan semua senario yang tidak diingini dengan anggun, tetapi apabila menggunakan ciri Java ini oleh pembangun, beberapa masalah mungkin timbul. Dalam artikel ini, saya tidak akan membincangkan cara Pengendalian Pengecualian berfungsi
di Jawa. Saya menganggap bahawa pembaca sudah biasa dengan hierarki pengecualian, pengecualian yang diperiksa
, pengecualian yang tidak ditanda
dan pengecualian masa jalan . Di sini kita akan membincangkan kesilapan yang paling biasa yang harus anda elakkan.
Pihak Berkepentingan dalam Pengecualian
Setiap kali urutan pelaksanaan terganggu, maklumat mengenainya mesti dikembalikan kepada pelaksana program. Urutan ini boleh bermula dari skrin, dari tugas kelompok atau dengan cara lain. Semua pencetus ini menunggu beberapa jenis pelanggaran dalam aliran untuk menghantar mesej dalam format tertentu. Pencetus berasaskan skrin boleh memberitahu kami secara perlahan-lahan bahawa terdapat beberapa isu teknikal dan kami harus menghubungi sokongan untuk mendapatkan bantuan dan nasihat. Proses kelompok atau program Java kendiri mungkin menjangkakan laporan ralat muncul dalam bentuk beberapa jenis log yang tidak dapat difahami sepenuhnya oleh pengguna akhir. Tetapi ahli perniagaan perlu menerima mesej dalam bahasa yang mereka fahami. NullPointerException yang digeruni dalam fikiran pengguna sangat menjengkelkan. Kadangkala ralat ini adalah akibat daripada penggunaan program yang salah, tetapi kadangkala ia adalah masalah yang memerlukan pembetulan. Pihak berkepentingan kedua yang penting ialah orang yang perlu menangani masalah yang dibangkitkan oleh pengecualian. Orang ini tidak dapat memerhatikan pelaksanaan sebenar program apabila pengecualian berlaku. Ia akan bergantung pada dua perkara - pertama, maklumat yang diberikan oleh pengguna yang menghadapi masalah, dan kedua, sejenis log yang dijana apabila pengecualian berlaku. Di samping itu, orang yang akan menganalisis masalah bukanlah orang yang sama yang menulis program, dan oleh itu pembangun program mesti menyediakan maklumat yang mencukupi untuk analisis. Satu-satunya cara komunikasi antara pembangun program dan penyahpepijatnya ialah log. Juga, kadangkala disebabkan oleh sebab keselamatan, log log kadangkala mungkin tidak mengandungi semua butiran sebenar pelaksanaan program apabila pengecualian berlaku. Mari kita lihat kemungkinan ralat dalam pengendalian pengecualian. Sesetengah daripada mereka kelihatan agak bodoh, tetapi ada orang. yang tidak memberi perhatian kepada mereka sehingga kesilapan ini membawa kepada masalah.
Blok pengecualian kosong
Ini adalah salah satu ralat yang paling tidak diingini dalam pengendalian pengecualian. Dalam kes ini, pengecualian hanya diabaikan. Penyelesaiannya tidak mengandungi apa-apa kecuali baris komen untuk meninggalkan pengecualian.
try{ }catch(SQLException sqe){ // do nothing } Dalam beberapa kes yang jarang berlaku, seperti dalam blok terakhir apabila pangkalan data ditutup, pengecualian mungkin dilemparkan. Dalam kes ini, mereka boleh diabaikan.
try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }
Generalisasi mesej pengecualian yang salah
Perkara ini adalah subjektif. Selepas menangkap pengecualian, anda boleh melaporkannya kepada pengguna akhir dalam bentuk mesej mesra. Ada kemungkinan bahawa butiran mesej asal akan hilang apabila mesej asal ditukar menjadi satu mesej umum. Mesej harus menyampaikan maklumat yang betul kepada pengguna akhir supaya apabila menghubungi pasukan sokongan, pengguna hanya perlu log masuk ke log yang sesuai untuk memberikan maklumat.
try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } Dalam aplikasi berbilang peringkat, setiap lapisan menangkap pengecualian dan melemparkan jenis pengecualian baharu. Kadang-kadang sangat perlu untuk membuang pengecualian jenis tertentu: - Lapisan Akses Data -> mencipta DataAccessException - Lapisan Pelaksanaan Perniagaan -> mencipta BusinessException - Lapisan Perkhidmatan Aplikasi -> mencipta ApplicationServiceException Semuanya nampak logik, bukan? Di sini kita mungkin perlu memilih antara ApplicationServiceException dan BusinessException kerana kedua-duanya boleh mewakili maklumat yang sama. Salah satu daripada penukaran pengecualian ini nampaknya tidak perlu.
Memusnahkan kelas StackTrace
Semasa proses menukar pengecualian kepada jenis khas baharu, jejak tindanan mungkin hilang, menjadikan pengesanan punca sebenar pengecualian itu sebagai mimpi ngeri. Dalam kod di bawah anda boleh melihat bagaimana pengecualian baharu dilemparkan tanpa menerima sebarang maklumat daripada pengecualian asal.
try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }
Menimpa sebab pengecualian
Setiap mesej pengecualian mengandungi maklumat tentang sebab pengecualian. Walau bagaimanapun, apabila pengecualian baharu dibuat, maklumat tentang yang lama mungkin dipadamkan secara kekal. Ini serupa dengan contoh di atas di mana StackTrace mungkin dialih keluar kerana pengecualian baharu dilemparkan.
Tiada mencari pengecualian khusus
Kadangkala pembangun suka bermain selamat apabila mengendalikan pengecualian. Kadang-kadang ini mudah dilakukan. Tetapi menangkap java.lang.Exception dan bukannya pengecualian khusus tidak boleh diterima.
try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }
Tangkap dan buang yang tidak perlu
Tangkap pengecualian jika anda ingin menukarnya kepada jenis lain, atau jika ia membantu anda menambahkan beberapa maklumat pada mesej pengecualian kepada pengguna akhir atau penganalisis. Jika tidak, buangnya lebih jauh dalam tandatangan kaedah (menggunakan lontaran) dan bukannya menangkapnya.
Menangkap RuntimeException
Saya akan mengesyorkan mengelakkan menangkap RuntimeException. Sebaliknya, adalah lebih baik untuk menangkap pengecualian khusus dan merawatnya.
Mencari pengecualian yang tidak ditandai
Ia adalah topik kontroversi sama ada untuk menangkap pengecualian yang tidak disemak atau tidak. NullPointerException dan ArrayIndexOutOfBound mungkin merupakan contoh terbaik bagi pengecualian yang tidak disemak. Daripada menangkap pengecualian ini, anda boleh menukar kod anda untuk mengendalikan senario ini. Contohnya, untuk mengelakkan NullPointerException, untuk memastikan semua pembolehubah dimulakan, untuk mengelakkan pengecualian ArrayIndexOutOfBound, untuk menentukan tatasusunan dengan panjang yang betul, dsb.
Isu berkaitan pengelogan pengecualian
Majalah itu akan membantu orang yang berminat kedua, iaitu orang yang menganalisis masalah. Kadangkala pembangun melampaui batas dengan fail log dan log dibuat pada setiap peringkat aplikasi. Log harus merekodkan pengecualian pada tahap di mana ia berlaku. Nampaknya optimum untuk memaparkan amaran bahawa pengecualian telah berlaku, dengan cadangan untuk menghentikan atau meneruskan pelaksanaan program, dan pengelogan mandatori pengecualian dalam log.
Pengecualian kawalan aliran
Pengecualian ialah gangguan kepada aliran biasa program, yang bermaksud anda perlu mengganggu aliran ini dan memaklumkan pengguna akhir mengenainya. Jika kami menambah panggilan kaedah yang merupakan urutan alternatif, ia akan membawa kepada masalah penyelenggaraan yang besar.
try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }
Penggunaan java.lang.Exception di mana-mana
Ia juga bukan idea yang baik untuk menggunakan java.lang.Exception di mana-mana sahaja untuk sebarang pengecualian. Sebaliknya, lebih baik menggunakan pengecualian khusus aplikasi, atau pengecualian Java standard yang paling sesuai.
Artikel asal: Kesilapan Biasa dalam Pengendalian Pengecualian Diterjemah dan disuarakan oleh: Ve4niY
GO TO FULL VERSION