Mengapa berbicara tentang penanganan pengecualian dalam proyek J2EE? Mungkin banyak pemula Java ingin mengatakan, "Bukankah pengecualian menangani hanya mencoba .... Tangkap ... akhirnya? Semua orang tahu ini!" Penulis juga berpikir seperti ini ketika dia adalah seorang pemula di Java. Bagaimana cara menentukan kelas pengecualian yang sesuai dalam proyek J2EE multi-lapisan? Bagaimana cara menangani pengecualian di setiap lapisan dalam proyek? Kapan pengecualian dilemparkan? Kapan pengecualian dicatat? Bagaimana cara merekam pengecualian? Kapan saya harus mengubah pengecualian yang diperiksa menjadi pengecualian yang tidak dicentang, dan kapan saya harus mengubah pengecualian yang tidak dicentang menjadi pengecualian yang diperiksa? Haruskah pengecualian disajikan ke halaman front-end? Bagaimana cara merancang kerangka kerja pengecualian? Masalah -masalah ini akan dibahas dalam artikel ini.
1. Penanganan Pengecualian Java
Dalam bahasa pemrograman prosedural, kita dapat menentukan apakah metode ini dijalankan secara normal dengan mengembalikan nilai. Misalnya, dalam program yang ditulis dalam bahasa C, jika metode dieksekusi dengan benar, itu akan mengembalikan 1. Jika kesalahan dijalankan, itu akan mengembalikan 0. Dalam aplikasi yang dikembangkan oleh VB atau Delphi, ketika kesalahan terjadi, kami akan memunculkan kotak pesan kepada pengguna.
Kami tidak bisa mendapatkan detail kesalahan melalui nilai pengembalian metode. Mungkin karena metode ini ditulis oleh programmer yang berbeda, ketika jenis kesalahan yang sama terjadi dalam metode yang berbeda, hasil yang dikembalikan dan informasi kesalahan tidak konsisten.
Oleh karena itu, bahasa Java mengadopsi mekanisme penanganan pengecualian terpadu.
Apa itu pengecualian? Kesalahan yang dapat ditangkap dan dapat diproses terjadi saat runtime.
Dalam bahasa Java, pengecualian adalah kelas induk dari semua pengecualian. Pengecualian apa pun diperluas ke kelas pengecualian. Pengecualian setara dengan jenis kesalahan. Jika Anda ingin mendefinisikan jenis kesalahan baru, rentangkan subclass pengecualian baru. Keuntungan menggunakan pengecualian adalah bahwa ia dapat secara akurat menemukan lokasi kode sumber yang menyebabkan kesalahan program dan mendapatkan informasi kesalahan terperinci.
Penanganan Java Exception diimplementasikan melalui lima kata kunci, mencoba, menangkap, melempar, melempar, akhirnya. Struktur penanganan pengecualian spesifik diimplementasikan oleh try .... .catch .... akhirnya blok. Pernyataan TREE BLOCK Java yang mungkin memiliki pengecualian. Tangkapan digunakan untuk menangkap terjadinya pengecualian dan menangani pengecualian. Blok terakhir digunakan untuk menghapus sumber daya yang tidak bebas dalam program. Blok terakhir selalu dieksekusi jika kode yang tidak mengelola bagaimana blok coba kembali.
Kode penanganan pengecualian khas
String publik getPassword (string userId) melempar dataAccessException {string sql = "Pilih kata sandi dari userInfo di mana userid = '" +userid +"'"; string kata sandi = null; koneksi con = null; pernyataan s = null; hasil rs = null; coba {con = getConnection (); // dapatkan koneksi data sl = con = null; con = con = getConnection ();/Get Data Connection sl = con = null; con = con = getConnection ();/Get Data Connecner Sl =. S.ExecuteQuery (SQL); while (rs.next ()) {password = rs.getString (1);} rs.close (); s.close ();} catch (sqlexception ex) {throw DataAccessException baru (ex);} Akhirnya {coba {if (con! = null) {con.close ();}} {SQ) {con.close {con.close ();}} Catch (SQ) {con.close ();}} Catch (SQ) {con.close ();} {SQ) {CONEXECSECSEON (); gagal! ", sqlex);}} mengembalikan kata sandi;} Dapat dilihat bahwa keuntungan dari mekanisme penanganan pengecualian Java:
Kesalahan diklasifikasikan secara seragam dan diimplementasikan dengan memperluas kelas pengecualian atau subkelasnya. Ini menghindari kesalahan yang sama mungkin memiliki pesan kesalahan yang berbeda dalam metode yang berbeda. Ketika kesalahan yang sama terjadi dalam metode yang berbeda, Anda hanya perlu melempar objek pengecualian yang sama.
Dapatkan informasi kesalahan yang lebih rinci. Melalui kelas pengecualian, informasi kesalahan dapat diberikan kepada pengecualian yang lebih rinci dan lebih berguna bagi pengguna. Mudah bagi pengguna untuk melacak dan men -debug program.
Pisahkan hasil pengembalian yang benar dari pesan kesalahan. Mengurangi kompleksitas program. Penelepon tidak perlu tahu lebih banyak tentang hasil pengembalian.
Paksa penelepon untuk menangani pengecualian untuk meningkatkan kualitas program. Ketika deklarasi metode perlu melempar pengecualian, penelepon harus menggunakan blok coba .... untuk menangani pengecualian. Tentu saja, penelepon juga dapat memungkinkan pengecualian untuk terus dilemparkan ke tingkat atas.
2. Pengecualian diperiksa atau pengecualian yang tidak dicentang?
Pengecualian Java dibagi menjadi dua kategori: pengecualian yang diperiksa dan pengecualian yang tidak dicentang. Semua pengecualian yang mewarisi java.lang.Exception termasuk pengecualian yang diperiksa. Semua pengecualian yang mewarisi java.lang.runtimeException termasuk pengecualian yang tidak dicentang.
Ketika suatu metode memanggil metode yang mungkin melempar pengecualian yang diperiksa, pengecualian harus ditangkap dan diproses atau dilemparkan kembali melalui blok Cobalah ... Catch.
Mari kita lihat deklarasi metode createStatement () dari antarmuka koneksi.
Pernyataan Publik CreateStatement () melempar SQlexception; SQlexception adalah pengecualian yang diperiksa. Ketika metode createestatement dipanggil, Java memaksa penelepon untuk menangkap SQLException. Public String getPassword (string userId) {coba {... pernyataan s = con.createStatement (); ... catch (sqlexception sqlex) {...} ...} atau
Public String getPassword (string userId) melempar sqlexception {pernyataan s = con.createestatement ();} (Tentu saja, sumber daya seperti koneksi dan satement perlu ditutup pada waktunya. Ini hanya untuk menggambarkan bahwa pengecualian yang diperiksa harus memaksa penelepon untuk menangkap atau terus melempar)
Pengecualian yang tidak dicentang juga disebut pengecualian runtime. Biasanya, RuntimeException menunjukkan pengecualian bahwa pengguna tidak dapat memulihkan, seperti ketidakmampuan untuk mendapatkan koneksi basis data, ketidakmampuan untuk membuka file, dll. Meskipun pengguna juga dapat menangkap pengecualian yang tidak dicentang seperti menangani pengecualian yang diperiksa. Tetapi jika penelepon tidak menangkap pengecualian yang tidak terkendali, kompiler tidak akan memaksa Anda untuk melakukannya.
Misalnya, kode yang mengubah karakter menjadi nilai integer adalah sebagai berikut:
String str = "123"; nilai int = integer.parseint (str);
Tanda tangan metode parseint adalah:
Public StaticInt ParseInt (String S) melempar NumberFormatException
Ketika parameter yang diteruskan tidak dapat dikonversi menjadi integer yang sesuai, NumberFormatException akan dilemparkan. Karena NumberFormateException meluas ke runtimeException, itu adalah pengecualian yang tidak dicentang. Jadi tidak perlu mencoba ... menangkap saat memanggil metode parseint
Karena Java tidak memaksa penelepon untuk menangkap atau melempar pengecualian yang tidak terkendali. Jadi pemrogram selalu suka melempar pengecualian yang tidak terkendali. Atau ketika kelas pengecualian baru diperlukan, itu selalu digunakan untuk memperluas dari runtimeException. Saat Anda memanggil metode ini, jika tidak ada blok tangkapan yang sesuai, kompiler akan selalu membiarkan Anda lulus, dan Anda tidak perlu memahami pengecualian apa yang akan dilemparkan metode ini. Sepertinya ini adalah ide yang bagus, tetapi melakukan itu jauh dari niat nyata penanganan pengecualian Java. Dan itu menyesatkan bagi programmer yang memanggil kelas Anda, karena penelepon tidak tahu dalam keadaan apa yang dibutuhkan untuk menangani pengecualian. Pengecualian yang diperiksa dapat dengan jelas memberi tahu penelepon apa yang perlu ditangani saat memanggil kelas ini. Jika penelepon tidak memprosesnya, kompiler akan meminta dan tidak dapat dikompilasi dan dilewati. Tentu saja, bagaimana menghadapinya terserah penelepon untuk memutuskan.
Jadi Java merekomendasikan agar orang harus menggunakan pengecualian yang diperiksa dalam kode aplikasi mereka. Sama seperti yang kami sebutkan di bagian sebelumnya bahwa keuntungan menggunakan pengecualian adalah bahwa ia dapat memaksa penelepon untuk menangani pengecualian yang akan dihasilkan. Pengecualian yang diperiksa digunakan sebagai standar dalam dokumen Java resmi seperti "Tutorial Java".
Menggunakan pengecualian yang diperiksa harus berarti bahwa ada banyak mencoba ... tangkapan dalam kode Anda. Setelah menulis dan menangani lebih banyak dan lebih banyak mencoba ... tangkap blok, banyak orang akhirnya mulai bertanya -tanya apakah pengecualian diperiksa harus digunakan sebagai standar.
Bahkan Bruce Eckel, penulis "Thinking in Java" yang terkenal, mengubah pikirannya sebelumnya. Bruce Eckel bahkan menganjurkan menggunakan pengecualian yang tidak dicentang sebagai penggunaan standar. Dan mempublikasikan artikel untuk menguji apakah pengecualian yang diperiksa harus dihapus dari Java. Bruce Eckel: "Ketika sejumlah kecil kode, pengecualian yang diperiksa tidak diragukan lagi merupakan konsep yang sangat elegan dan membantu menghindari banyak kesalahan potensial. Tetapi pengalaman menunjukkan bahwa hasilnya justru sebaliknya dengan sejumlah besar kode."
Untuk diskusi terperinci tentang pengecualian yang diperiksa dan pengecualian yang tidak dicentang, silakan merujuk ke
Java Tutorial http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
Menggunakan pengecualian yang diperiksa dapat menyebabkan banyak masalah.
Pengecualian yang diperiksa menyebabkan terlalu banyak mencoba ... Tangkap kode
Mungkin ada banyak pengecualian yang diperiksa yang tidak dapat ditangani secara wajar oleh pengembang, seperti SQlexception. Tapi pengembang harus mencoba ... menangkap. Ketika pengembang tidak dapat menangani pengecualian yang diperiksa dengan benar, mereka biasanya hanya mencetak pengecualian atau tidak melakukan apa -apa. Khusus untuk pemula, terlalu banyak pengecualian yang diperiksa membuatnya merasa bingung.
coba {... pernyataan s = con.createStateMent (); ... catch (sqlexception sqlex) {sqlex.printstacktrace ();} atau
coba {... pernyataan s = con.createStatement (); ... catch (sqlexception sqlex) {// do nothing} Pengecualian diperiksa menyebabkan banyak pembuatan kode yang sulit dipahami
Ketika pengembang harus menangkap pengecualian yang tidak dapat ditangani dengan benar, mereka biasanya dikemas ulang menjadi pengecualian baru dan kemudian dilemparkan. Melakukan hal itu tidak membawa manfaat apa pun pada program. Sebaliknya, itu membuat kode sulit dipahami nanti.
Sama seperti kita menggunakan kode JDBC, ada banyak mencoba ... Catch. Kode yang sangat berguna termasuk dalam TREE ... Catch. Membuatnya sulit untuk memahami metode ini
Pengecualian diperiksa menyebabkan pengecualian terus -menerus dienkapsulasi ke dalam pengecualian kelas lain dan kemudian dilemparkan
public void methoda () melempar Exceptiona {... ..Throw new exceptiona ();} public void MethodB () melempar ExceptionB {try {Methoda (); ...} catch (Exceptiona ex) {throw new ExceptionB (ex);}} public void Methodc () lemparan {try {try {try {methodb (); ExceptionC (ex);}} Kita melihat bahwa pengecualian dienkapsulasi dan dilemparkan kembali lapisan demi lapis.
Pengecualian diperiksa menyebabkan metode antarmuka korupsi
Metode pada antarmuka telah digunakan oleh beberapa kelas. Ketika pengecualian diperiksa tambahan ditambahkan ke metode ini, semua kode yang memanggil metode ini perlu dimodifikasi.
Dapat dilihat bahwa masalah di atas dipaksa untuk menangkap dan memproses karena penelepon tidak dapat menangani pengecualian yang diperiksa dengan benar, dan dipaksa untuk merangkum dan kemudian dilemparkan kembali. Ini sangat tidak nyaman dan tidak membawa manfaat apa pun. Dalam hal ini, pengecualian yang tidak dicentang biasanya digunakan.
Pengecualian yang diperiksa tidak semua. Pengecualian yang diperiksa jauh lebih mudah digunakan daripada nilai pengembalian kesalahan pemrograman tradisional. Jauh lebih baik untuk memastikan bahwa pengecualian ditangani dengan benar melalui kompiler daripada menilai dengan nilai pengembalian.
Jika pengecualian berakibat fatal, itu tidak dapat dipulihkan. Atau penelepon pergi untuk menangkapnya tanpa manfaat, gunakan pengecualian yang tidak dicentang.
Jika pengecualian dapat dipulihkan dan dapat ditangani dengan benar oleh penelepon, gunakan pengecualian yang diperiksa.
Saat menggunakan pengecualian yang tidak terkendali, pengecualian yang tidak dikalahkan yang dapat dilemparkan metode harus dijelaskan secara rinci dalam deklarasi metode. Penelepon memutuskan apakah akan menangkap pengecualian yang tidak terkendali
Kapan menggunakan pengecualian yang diperiksa, dan kapan menggunakan pengecualian yang tidak terkendali? Tidak ada standar absolut. Tapi saya bisa memberikan beberapa saran
Ketika semua penelepon harus menangani pengecualian ini, penelepon dapat diizinkan untuk mencoba lagi operasi; atau pengecualian setara dengan nilai pengembalian kedua dari metode ini. Gunakan pengecualian yang diperiksa.
Pengecualian ini hanya dapat ditangani oleh beberapa penelepon yang lebih maju, dan penelepon biasa tidak dapat menanganinya dengan benar. Gunakan pengecualian yang tidak dicentang. Penelepon yang memiliki kemampuan untuk memproses dapat melakukan pemrosesan lanjutan, tetapi umumnya penelepon tidak menanganinya sama sekali.
Pengecualian ini adalah kesalahan yang sangat serius, seperti kesalahan koneksi basis data, kegagalan file untuk membuka, dll. Atau pengecualian ini terkait dengan lingkungan eksternal. Tidak mungkin menyelesaikan masalah mencoba kembali. Gunakan pengecualian yang tidak dicentang. Karena begitu pengecualian ini terjadi, penelepon tidak dapat menanganinya sama sekali.
Jika tidak yakin, gunakan pengecualian yang tidak dicentang. Dan jelaskan secara rinci pengecualian yang mungkin dilemparkan untuk membiarkan penelepon memutuskan apakah akan menanganinya.
3. Desain kelas pengecualian baru
Saat merancang kelas pengecualian baru, pertama -tama periksa apakah kelas pengecualian ini benar -benar diperlukan. Secara umum, cobalah untuk tidak merancang kelas pengecualian baru, tetapi cobalah menggunakan kelas pengecualian yang sudah ada di Java.
menyukai
IllegalargumentException, UnsportedOperationException
Apakah itu pengecualian baru, pengecualian chekced atau pengecualian yang tidak terkendali. Kita semua harus mempertimbangkan masalah bersarang dari pengecualian.
public void methoda () melempar Exceptiona {... ..Throw New Exceptiona ();} Metode MethodA Deklarasi melempar Exceptiona.
Metode public void () melempar ExceptionB
Deklarasi MethodB akan melempar ExceptionB. Ketika Methoda dipanggil dalam metode MethodB, Excepona tidak dapat diproses, sehingga Exceptiona harus terus muntah. Salah satu caranya adalah dengan membuat deklarasi MethodB melempar Exceptiona. Tetapi ini telah mengubah tanda tangan metode MethodB. Setelah diubah, semua metode yang harus diubah. Metode Call harus diubah.
Cara lain adalah dengan merangkum Exceptiona menjadi ExceptionB dan kemudian melemparkannya. Jika kami tidak merangkum Exceptiona di ExceptionB, kami akan kehilangan informasi pengecualian root, sehingga tidak mungkin untuk melacak sumber asli pengecualian.
public void methodB () melempar ExceptionB {try {Methoda (); ...} catch (Exceptiona ex) {throw new ExceptionB (ex);}} Seperti pada kode di atas, pengecualian sarang pengecualian. Kami akan menyebut Excepona "menyebabkan pengecualian" untuk saat ini, karena Exceptiona menyebabkan pengecualian terjadi. Ini akan mencegah informasi pengecualian hilang.
Jadi ketika kami mendefinisikan kelas pengecualian baru, kami harus menyediakan konstruktor yang dapat berisi pengecualian bersarang. Dan ada anggota pribadi untuk menyimpan "pengecualian penyebab" ini.
Kelas publik ExceptionB Memperluas Exception {Private Throwable Cause; Public ExceptionB (String Msg, Throwable Ex) {super (msg); this.Cause = ex;} public ExceptionB (string msg) {super (msg);} public ExceptionB (Throwable ex) {this.Cause = ex;}} Tentu saja, ketika kita memanggil metode PrintStackTrace, kita perlu mencetak semua informasi "pengecualian yang disebabkan" secara bersamaan. Jadi kita perlu mengganti metode PrintStackTrace untuk menampilkan semua jejak tumpukan pengecualian. Termasuk jejak tumpukan pengecualian bersarang.
public void printStackTrace (printStrean ps) {if (penyebab == null) {super.printstacktrace (ps);} else {ps.println (this); cause.printstacktrace (ps);}} Dukungan lengkap untuk kode sumber kelas pengecualian bersarang diperiksa adalah sebagai berikut. Sebut saja NestedException di sini untuk saat ini
Publik NestedException memperluas Exception {Private Throwable Cause; Public NestedException (String msg) {super (msg);} nestedException publik (string msg, lempar ex) {super (msg); this.cause = ex;} public lempar getCause () {return (this.Cause == null? this: this: this: this: this: this. this. ini: super.getMessage (); throwable cause = getCause (); if (cause! = null) {message = pesan + "; pengecualian bersarang adalah" + penyebab;} pesan kembali;} public void printStackTrace (printStream PS) {if (getCause == null) {super.printstacktrace (ps);} else {ps.println (this); getCause (). printStacktrace (ps);}} public void printStackTrace (printwrite pw) {if (getCause () == null) {super.printstacktrace (pw);} else {pw.println (this); getCause (). printstacktrace (pw);}} public void printStackTrace () {printStackTrace (System.Error);}}Juga, Anda perlu merancang kelas pengecualian yang tidak dicentang seperti di atas. Itu hanya perlu mewarisi runtimeeException.
4. Cara mencatat pengecualian
Sebagai sistem aplikasi yang besar, file log diperlukan untuk merekam pengoperasian sistem untuk memfasilitasi pelacakan dan merekam pengoperasian sistem. Pengecualian yang terjadi dalam sistem secara alami perlu direkam dalam sistem log.
Public String getPassword (String UserId) melempar nosuchusexception {userInfo user = userdao.queryUserById (userId); if (user == null) {logger.info ("informasi pengguna tidak dapat ditemukan, userid ="+userid); lempar nosuchusexception {{{{Userid = " user.getPassword();}}public void sendUserPassword(String userId)throws Exception {UserInfo user = null;try{user = getPassword(userId);//…..sendMail();//}catch(NoSuchUserException ex)(logger.error("This user information cannot be found:"+userId+ex);throw new Exception(ex);} Kami memperhatikan bahwa kesalahan dicatat dua kali. Pada asal kesalahan yang hanya kami rekam di level info. Dalam metode SendUserPassword, kami juga mencatat seluruh informasi pengecualian.
Penulis telah melihat banyak proyek mencatat pengecualian dengan cara ini, terlepas dari 3721, dan seluruh pengecualian akan dicatat hanya ketika menemukan pengecualian. Jika pengecualian terus dienkapsulasi dan dilemparkan beberapa kali, itu akan direkam beberapa kali. Jadi di mana pengecualian harus direkam?
Pengecualian harus direkam di lokasi awal!
Jika Anda harus menangkap pengecualian yang tidak dapat ditangani dengan benar, hanya merangkumnya menjadi pengecualian lain dan melemparkannya. Tidak perlu merekam pengecualian yang direkam lagi.
Jika pengecualian ditangkap, pengecualian ini dapat ditangani. Tidak ada pengecualian yang perlu direkam
Tanggal Publik getDate (string str) {date applyDate = null; format SimpleDateFormat = new SimpleDateFormat ("mm/dd/yyyy"); coba {applyDate = format.parse (applyDateStr);} return (parseexception ex) {/wharse, ketika format salah, pengembalian parseexception ex) {/when, ketika format salah, pengembalian bekas unggul oLLEException { Ketika pengecualian yang tidak tercatat atau pengecualian sistem eksternal ditangkap, rincian pengecualian harus dicatat.
Coba {... String sql = "pilih * dari userInfo"; Pernyataan s = con.createStatement (); ... catch (sqlexception sqlex) {logger.error ("kesalahan eksekusi sql"+sql+sqlex);} Tempat mencatat informasi pengecualian dan cara merekam informasi pengecualian mungkin menjadi masalah pendapat. Beberapa sistem bahkan membiarkan pengecualian kelas pengecualian. Ketika objek pengecualian baru dihasilkan, informasi pengecualian dicatat secara otomatis.
Public Class BusinessException memperluas Exception {private void logTrace () {stringBuffer buffer = new StringBuffer (); buffer.append ("Kesalahan bisnis di kelas:"); buffer.append (getClasSname ()); buffer.append (", metode:"); buffer. "); buffer.append (this.getMessage ()); logger.error (buffer.toString ());} Public BusinessException (String s) {super (s); ras ();} Ini tampaknya sangat indah, tetapi pasti akan mengarah pada pengecualian yang direkam berulang kali. Pada saat yang sama, melanggar "prinsip distribusi tanggung jawab kelas" dan merupakan desain yang buruk. Pengecualian perekaman bukan milik perilaku kelas pengecualian, dan pengecualian pengecualian harus dilakukan oleh sistem penebangan khusus. Dan informasi perekaman abnormal terus berubah. Kami merekam pengecualian yang seharusnya memberikan informasi yang lebih kaya. Ini membantu kita menemukan akar penyebab masalah berdasarkan informasi pengecualian untuk menyelesaikan masalah.
Meskipun kami telah membahas banyak tentang mencatat pengecualian, terlalu banyak penekanan pada ini membuat pengembang lebih bingung. Salah satu cara yang baik adalah dengan memberikan kerangka kerja penanganan pengecualian untuk sistem. Kerangka kerja memutuskan apakah akan merekam pengecualian dan cara merekam pengecualian. Tidak terserah programmer biasa untuk memutuskan. Tetapi bermanfaat untuk mengetahui sesuatu.
5. Penanganan Pengecualian dalam Proyek J2EE
Saat ini, proyek J2EE umumnya dibagi menjadi beberapa lapisan secara logis. Yang klasik dibagi menjadi tiga lapisan: lapisan presentasi, lapisan bisnis, dan lapisan integrasi (termasuk akses basis data dan akses sistem eksternal).
Proyek J2EE memiliki kompleksitasnya, dan beberapa masalah perlu diberi perhatian khusus saat menangani pengecualian dalam proyek J2EE.
Saat menggunakan aplikasi terdistribusi, kami menemukan banyak pengecualian yang diperiksa. Semua panggilan RMI (termasuk panggilan antarmuka jarak jauh EJB) akan melempar java.rmi.remoteException; Pada saat yang sama, RemoteException adalah pengecualian yang diperiksa. Ketika kami melakukan panggilan jarak jauh di sistem bisnis, kita semua perlu menulis sejumlah besar kode untuk menangani pengecualian yang diperiksa ini. Setelah RemoteException terjadi, pengecualian yang diperiksa ini sangat serius untuk sistem, dan hampir tidak ada kemungkinan untuk mencoba lagi. Dengan kata lain, ketika pengecualian yang mengerikan dari RemoteException ini muncul, kita tidak perlu mencoba lagi, tetapi kita harus menulis banyak mencoba ... Tangkap kode untuk menanganinya. Secara umum, kami melakukan panggilan RMI di level bawah. Selama ada panggilan RMI, semua antarmuka tingkat atas akan memerlukan RemoteException untuk dilemparkan. Karena cara kita berurusan dengan RemoteException adalah dengan terus melemparkannya. Ini akan menghancurkan antarmuka bisnis kami. Remoteexception Pengecualian tingkat sistem J2EE ini secara serius memengaruhi antarmuka bisnis kami. Tujuan dari pelapisan sistem kita adalah untuk mengurangi ketergantungan antara sistem, dan perubahan teknologi di setiap lapisan tidak akan mempengaruhi lapisan lain.
// kelas publik UsersoImplImplIMPLES USERSOA {UserInInfo publik getUserInfo (String UserId) melempar RemoteException {//… Metode Remote Call.//……} - Public Interface UserManager {Public UserInfo getUserInfo (String UserId) Lempar Remoteexception;} public GetUserInfo (String UserId) melempar Remoteexception;}}}}}} {string string userid) Remoteexception; Demikian pula, akses JDBC akan melempar pengecualian sqlexception yang diperiksa.
Untuk menghindari intrusi mendalam dari pengecualian diperiksa tingkat sistem ke dalam sistem bisnis, kami dapat menentukan pengecualian sistem bisnis sendiri untuk metode bisnis. Untuk pengecualian yang sangat serius seperti SQLException dan RemoteException, kita dapat menentukan pengecualian baru yang tidak terkendali, dan kemudian merangkum sqlexception dan remoteexception menjadi pengecualian yang tidak dicentang dan melemparkannya.
Jika pengecualian tingkat sistem ini harus diserahkan kepada penelepon sebelumnya untuk ditangani, Anda dapat mendefinisikan pengecualian bisnis yang baru diperiksa, dan kemudian menyegel pengecualian tingkat sistem menjadi pengecualian tingkat bisnis dan kemudian melemparkannya.
Secara umum, kita perlu mendefinisikan pengecualian yang tidak dicentang, sehingga semua metode antarmuka lapisan integrasi menyatakan untuk melempar pengecualian yang tidak terkendali ini.
public DataAccessExceptionextends RuntimeException{...}public interface UserDao{public String getPassword(String userId)throws DataAccessException;}public class UserDaoImplimples UserDAO{public String getPassword(String userId)throws DataAccessException{String sql = "select password from userInfo where userId= '"+UserId+"' "; coba {... // jdbc memanggil s.executeQuery (sql);…} catch (sqlexception ex) {lempar DataAccessException baru (" Kueri Basis Data Gagal "+SQL, EX);}}} Tentukan pengecualian bisnis yang diperiksa, sehingga semua metode antarmuka lapisan bisnis menyatakan untuk melempar pengecualian yang diperiksa.
public class BusinessExceptionextends Exception{…..}public interface UserManager{public Userinfo copyUserInfo(Userinfo user)throws BusinessException{Userinfo newUser = null;try{newUser = (Userinfo)user.clone();}catch(CloneNotSupportedException ex){throw new BusinessException("The clone method is not didukung: "+userInfo.class.getName (), ex);}}} Lapisan representasi J2EE harus merupakan lapisan yang sangat tipis, dan fungsi utamanya adalah: mendapatkan permintaan halaman, merakit parameter halaman menjadi objek POJO, memanggil metode bisnis yang sesuai, dan kemudian meneruskan halaman, menyajikan data bisnis yang sesuai ke halaman. Lapisan presentasi perlu memperhatikan satu masalah. Lapisan presentasi perlu memverifikasi legitimasi data, seperti beberapa bidang input tidak dapat kosong, verifikasi panjang karakter, dll.
Semua parameter yang diteruskan dari J2EE ke latar belakang dari halaman adalah tipe karakter. Jika Anda memerlukan input parameter tipe numerik atau tanggal, nilai karakter harus dikonversi ke nilai numerik atau tanggal yang sesuai.
Jika parameter verifikasi kode lapisan representasi tidak valid, itu harus dikembalikan ke halaman asli, memungkinkan pengguna untuk memasukkan kembali data, dan meminta informasi kesalahan yang relevan.
Biasanya, parameter yang ditularkan dari halaman dikonversi menjadi nilai numerik, kita dapat melihat kode seperti itu
Modeandview handleRequest (permintaan httpservletRequest, respons httpservletResponse) melempar pengecualian {string agestr = request.getParameter ("usia"); int usia = integer.parse (agestr); ……… string ulang tahun = request.getParameter ("ulang tahun"); SimpleDateFormat Format = new SimpleDateFormat ("mm/dd/yyyy"); tanggal ulang tahun = format.parse (ulang tahun);} Kode di atas harus sering dilihat, tetapi ketika pengguna memasukkan karakter yang tidak dapat dikonversi ke integer dari halaman atau nilai tanggal yang salah.
Metode integer.parse () dilemparkan pengecualian yang tidak dicentang dengan NumberFormateException. Namun, pengecualian ini jelas bukan pengecualian yang fatal. Secara umum, ketika nilai yang dimasukkan oleh pengguna di bidang entri halaman adalah ilegal, kami harus meminta pengguna untuk masuk kembali. Tetapi begitu pengecualian yang tidak dicentang dilemparkan, tidak ada kesempatan untuk mencoba lagi. Kode seperti ini menyebabkan sejumlah besar informasi pengecualian ditampilkan pada halaman. Buat sistem kami terlihat sangat rapuh.
Demikian pula, metode SimpleDateFormat.parse () juga akan melempar pengecualian ParseException yang tidak dicentang.
Dalam hal ini, kita harus menangkap pengecualian yang tidak terkendali ini dan meminta pengguna untuk masuk kembali.
Modeandview handleRequest (permintaan httpservletRequest, respons httpservletResponse) melempar pengecualian {string agestr = request.getParameter ("usia"); string ulang tahun = request.getParameter ("ulang tahun"); int usia = 0; tanggal ulang tahun = null; coba {usia = integer. Ex) {error.Rect ("Age", "bukan nilai integer legal");} ……… coba {SimpleDateFormat format = new SimpleDateFormat ("mm/dd/yyyy"); ulang tahun = format.parse (ulang tahun);} not legal date a legal exception {{ulang tahun "not legal (" ulang tahun "," not legal exception ex) Format 'mm/dd/yyy');}} Pada lapisan presentasi, Anda harus mengetahui apakah metode panggilan akan melempar pengecualian yang tidak dicentang, dalam keadaan apa pengecualian ini akan dilemparkan, dan membuat pemrosesan yang benar.
Di lapisan presentasi, tidak perlu menangkap pengecualian secara umum. Jika pengecualian yang dilemparkan oleh metode bisnis yang disebut setara dengan nilai pengembalian kedua, dalam hal ini perlu ditangkap.
Di atas adalah semua konten artikel ini. Saya berharap ini akan membantu untuk pembelajaran semua orang dan saya harap semua orang akan lebih mendukung wulin.com.