Untuk aplikasi web, kesalahan tidak bisa dihindari, jadi kita harus mengambil tindakan pencegahan dan memberikan penanganan yang tepat untuk kemungkinan kesalahan. Faktanya, mekanisme penanganan kesalahan yang baik merupakan kriteria penting untuk mengukur kualitas aplikasi web. Bayangkan saja, ketika pengguna secara tidak sengaja memasukkan URL yang salah di browser atau ketika pengguna memberikan beberapa informasi yang menyebabkan program mengalami kesalahan, jika kami tidak menangani situasi ini, kami mengizinkan halaman kesalahan 404 atau 500 atau bahkan kesalahan tumpukan informasi disajikan di depan pengguna, yang pastinya akan membuat takut sebagian pengguna. Oleh karena itu, ketika kita mengembangkan aplikasi web, kita harus memiliki pemahaman penuh tentang mekanisme penanganan kesalahan.
Mari kita kembali ke ASP.NET dan mengajukan dua pertanyaan untuk dipikirkan semua orang: Berapa banyak mekanisme penanganan kesalahan yang disediakan ASP.NET? Jika beberapa mekanisme penanganan kesalahan digunakan secara bersamaan, apakah ada prioritas tertentu di antara mekanisme tersebut? Dengan mengingat pertanyaan ini, pertama-tama mari kita lihat file Web.Config yang paling umum:
<?xml version="1.0"?>
<konfigurasi>
<sistem.web>
<customErrors mode="Aktif" defaultRedirect="GenericErrorPage.htm">
<kesalahan statusCode="403" redirect="Error403.htm" />
<kesalahan statusCode="404" redirect="Error404.htm" />
</kesalahan khusus>
</sistem.web>
</konfigurasi>
Mengenai item pengaturan <customErrors>, saya rasa tidak perlu dijelaskan lebih lanjut. Mekanisme penanganan kesalahan pertama - menggunakan item konfigurasi <customErrors> di Web.Config harus menjadi yang paling umum digunakan.
Selanjutnya mari kita lihat file lain yang juga sangat umum digunakan: Global.asax. Ketika Anda menyebutkan dokumen ini, apa yang Anda pikirkan? Ya, itu adalah peristiwa yang berkaitan dengan dua objek aplikasi Web utama (Aplikasi dan Sesi). Di antara peristiwa-peristiwa ini, terdapat peristiwa terkait kesalahan yang termasuk dalam kategori Aplikasi - Kesalahan, dan metode pemrosesan peristiwa terkait adalah Application_Error. Seperti namanya, metode penanganan peristiwa ini akan dipanggil ketika terjadi kesalahan tingkat aplikasi, sehingga Anda dapat menambahkan kode dalam metode ini untuk menangani kesalahan tersebut, seperti yang ditunjukkan di bawah ini:
protected void Application_Error(object sender, EventArgs e) {
Pengecualian objErr = Server.GetLastError().GetBaseException();
Response.Write("Kesalahan:" + objErr.Pesan);
Server.ClearError();
}
Di sini, setiap orang harus memperhatikan penggunaan Server.ClearError() pada baris kode terakhir. Apa yang terjadi jika Anda tidak menggunakannya? Di sini saya akan mencobanya lagi. Nah, mekanisme penanganan error yang kedua - menggunakan metode penanganan event Application_Error di Global.asax juga telah memulai debutnya.
Kedua metode penanganan error di atas bisa dikatakan bersifat global, yang satu berasal dari file konfigurasi aplikasi, dan yang lainnya adalah metode penanganan event file Global.asax yang harus ditempatkan di direktori root aplikasi. Kebalikan dari global adalah lokal, sehingga kita tentu bertanya-tanya: Apakah ada mekanisme penanganan kesalahan yang berlaku untuk lokal - halaman tertentu? Jawabannya adalah "ya", dan ada dua cara - menggunakan atribut ErrorPage dan menggunakan metode penanganan event Page_Error. Untuk mekanisme pertama, Anda dapat mengatur properti ErrorPage hampir kapan saja untuk menentukan halaman mana yang akan dialihkan ketika terjadi kesalahan pada halaman; untuk mekanisme kedua, sangat mirip dengan metode penanganan event Application_Error, kecuali Tapi waktu pemicunya berbeda. Berikut ini adalah dua contoh spesifik:
<script Language="C#" runat="server">
protected void Page_Load(pengirim objek, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</skrip>
protected void Page_Error(pengirim objek, EventArgs e) {
Pengecualian objErr = Server.GetLastError().GetBaseException();
Response.Write("Kesalahan:" + objErr.Pesan);
Server.ClearError(); //Perhatikan juga penggunaan kode ini
}
Pada titik ini, keempat mekanisme penanganan kesalahan semuanya telah muncul, dan sekarang saatnya untuk menentukan peringkatnya. Urutkan dari prioritas tinggi ke rendah: Metode penanganan kejadian Page_Error > Properti ErrorPage > Metode penanganan kejadian Application_Error > item konfigurasi <customErrors>. Meskipun peringkatnya seperti ini, ada hubungan yang halus antara peringkat tersebut. Pertama-tama, agar atribut ErrorPage berfungsi, atribut mode di item konfigurasi <customErrors> harus disetel ke "Aktif"; kedua, meskipun metode pemrosesan peristiwa Page_Error berada di peringkat pertama, jika metode Server.ClearError() berada hilang Jika demikian, penanganan kesalahan dengan prioritas lebih rendah akan tetap dipicu. Hal ini juga berlaku untuk metode penanganan kejadian Application_Error. Urutannya sudah diatur, namun urutan bukanlah masalah yang terpenting, bahkan bisa dikatakan sebagai masalah yang tidak terlalu berarti, karena dalam banyak kasus, Anda tidak boleh mencampurkan keempat mekanisme pemrosesan tersebut. Menurut saya, isu yang paling penting adalah bagaimana memilih mekanisme penanganan kesalahan ini. Mengenai masalah ini, saya berharap teman-teman yang berpengalaman dapat memberikan pendapatnya.
Oke, itu saja untuk memperkenalkan empat mekanisme penanganan kesalahan ASP.NET, dan sekarang saatnya membicarakan beberapa perasaan saya sendiri. Para perancang ASP.NET memang telah melakukan pertimbangan yang matang dari sudut pandang pengembang, sehingga mereka menyediakan sebanyak empat mekanisme penanganan kesalahan untuk kita pilih, yang patut diapresiasi. Namun untuk memparafrasekan slogan periklanan - terlalu banyak membingungkan, kita juga akan sedikit pusing dengan banyaknya mekanisme penanganan kesalahan. Membandingkan penanganan kesalahan di bidang J2EE, kita dapat menemukan bahwa ini relatif sederhana. Yang pertama adalah pengaturan yang sesuai dengan <customErrors>. Kita juga dapat menemukan item konfigurasi serupa dari file web.xml yang paling umum digunakan dalam proyek J2EE: <errorPage>; kedua, di bidang J2EE, Halaman bukanlah entitas penting dan event Model driver tidak diperlukan, jadi saya benar-benar tidak dapat menemukan mekanisme pemrosesan yang sesuai untuk metode Application_Error dan Page_Error; akhirnya, di bidang J2EE, lebih banyak penekanan ditempatkan pada Permintaan dan Respons , Kami dapat dengan mudah mendistribusikan Permintaan ke modul penanganan kesalahan yang sesuai melalui RequestDispatcher. Sebenarnya, ini adalah metode pemrosesan yang sangat fleksibel. Teman-teman yang tertarik mungkin ingin mempelajarinya.