Baik di asp atau asp.net, respon.end menghentikan konten keluaran dan sebagian besar digunakan untuk men-debug program. Ini juga sangat berguna, mirip dengan pengaturan breakpoint, terutama ketika program Anda memiliki masalah besar, seperti loop tak terbatas. write tidak dapat melihat hasil antara. Dalam hal ini, tambahkan respon.end setelah respon.tulis.
Pertama mari kita bicara tentang manfaatnya.
Ini juga sangat berguna saat men-debug suatu program. Ini mirip dengan pengaturan breakpoint, terutama jika program Anda memiliki masalah besar, misalnya ketika ada loop tak terbatas, dalam kasus ini hasil antara tidak dapat dilihat , setelah respon.tulis Tambahkan respon.end, yang berguna untuk melihat hasil antara.
Namun, jika Anda menggunakan metode Response.End, Response.Redirect, atau Server.Transfer, ThreadAbortException akan terjadi. Anda dapat menangkap pengecualian ini menggunakan pernyataan try-catch.
Metode Response.End menghentikan eksekusi halaman dan mengalihkan eksekusi ke peristiwa Application_EndRequest di alur peristiwa aplikasi. Baris kode berikut Response.End tidak dieksekusi.
Masalah ini terjadi pada metode Response.Redirect dan Server.Transfer karena kedua metode memanggil Response.End secara internal.
Larutan:
Untuk mengatasi masalah ini, gunakan salah satu metode berikut ini:
• Untuk Response.End, panggil metode HttpContext.Current.ApplicationInstance.CompleteRequest alih-alih Response.End untuk melewati eksekusi kode untuk kejadian Application_EndRequest.
• Untuk Response.Redirect, gunakan kelebihan Response.Redirect(String url, bool endResponse), yang meneruskan false pada parameter endResponse untuk membatalkan panggilan internal ke Response.End. Misalnya:
Respon.Redirect (Default.aspx, salah);
Response.End() penggunaan
Dalam pengembangan ASP, terkadang Anda menggunakan penilaian if...else dalam jumlah besar. Namun, jika ini adalah konten Response.write yang dinamis dan Anda ingin membuatnya lebih mudah untuk membaca kode, Anda dapat menggunakan Response.End() untuk menghentikan eksekusi ASP. Hal ini mirip dengan penggunaan Break, misalnya:
if (userid=)or(password=)then Response.Write() Response.End() 'Inilah akhir interupsi if Berikut ini operasi pembacaan database jika tidak kosong dengan menghilangkan n baris kode
Dengan cara ini, ketika nama pengguna atau kata sandi yang masuk kosong, informasi prompt secara otomatis ditulis, dan kemudian Response.End() menginterupsi program untuk mencapai if. . . Peran orang lain.
Selain itu, saat menggunakan Response.End, itu adalah saat kita men-debug program setiap hari, seperti
Untuk mengeluarkan pernyataan SQL yang disambung tanpa menjalankan kode berikut, Anda dapat melakukan ini
sql=pilih * dari userinfo respon.Write(sql)response.End()rs.open sql ,conn,1,1 'Kalimat ini tidak akan dieksekusi
Jika Anda takut terlalu banyak tempat untuk menambahkan Response.End() dan tidak mudah untuk berkomentar saat dirilis secara resmi, Anda dapat merangkumnya dengan fungsi, seperti kode berikut:
sub debug() Respons.End()end sub
Kode di atas dimodifikasi sebagai berikut:
sql=pilih * dari respon info pengguna. Tulis(sql)debug()rs.open sql ,sambungan,1,1 'Kalimat ini tidak akan dieksekusi
Dengan cara ini, ketika dirilis secara resmi, mengomentari pernyataan dalam fungsi debug dapat memainkan peran debugging. Namun, ada juga masalah dengan ini. Jika Anda menggunakan terlalu banyak debug(), program mungkin tidak dapat melakukannya ikuti instruksi selama proses debug. Interupsi diperlukan. Terkadang Anda tidak ingin eksekusi terhenti di tempat ini, jadi mari kita rekonstruksi lebih lanjut fungsi debug(), sebagai berikut:
sub debug(isBreak) 'isBreak adalah parameter dengan nilai boolean. Jika disetel ke true, maka sub endend Response.End() tidak akan dilakukan
Kode saat digunakan adalah sebagai berikut:
sql=pilih * dari respon info pengguna.Write(sql)debug(false)rs.open sql ,sambung,1,1 'Kalimat ini akan dieksekusi rs.close()sql=select * dari respon produk.write(sql) debug (true)rs.open sql,conn,1,1 'Kalimat ini tidak akan dieksekusi
Oke, ini pada dasarnya dapat memenuhi kebutuhan kita untuk mengontrol interupsi, tetapi ini hanya analisis sederhana, sebenarnya masih sangat tidak sempurna, mungkin masih banyak lagi persyaratan debugging yang perlu dipenuhi dan diperlukan rekonstruksi lebih lanjut. Faktanya, pengembangan program adalah proses refactoring, refactoring, dan refactoring. Jika tidak, akan ada begitu banyak pola desain. Itu semua adalah pengalaman yang dirangkum oleh para pendahulu dari proses pengembangan dan refactoring yang sebenarnya, dan patut untuk dipelajari.