ไม่ว่าจะเป็นใน asp หรือ asp.net การตอบกลับจะยุติเนื้อหาเอาต์พุตและส่วนใหญ่จะใช้สำหรับการแก้ไขข้อบกพร่องของโปรแกรมอีกด้วย คล้ายกับการตั้งค่าเบรกพอยต์ โดยเฉพาะอย่างยิ่งเมื่อโปรแกรมของคุณมีปัญหาสำคัญ เช่น การตอบสนองแบบไม่มีที่สิ้นสุด write ไม่เห็นผลลัพธ์ระดับกลาง ในกรณีนี้ ให้เพิ่ม response.end หลัง response.write ซึ่งมีประโยชน์มากสำหรับการดูผลลัพธ์ระดับกลาง
ก่อนอื่นเรามาพูดถึงประโยชน์ของมันกันก่อน
นอกจากนี้ยังมีประโยชน์มากเมื่อทำการดีบักโปรแกรม ซึ่งคล้ายกับการตั้งค่าเบรกพอยต์ โดยเฉพาะอย่างยิ่งหากโปรแกรมของคุณมีปัญหาสำคัญ ตัวอย่างเช่น เมื่อมีการวนซ้ำไม่สิ้นสุด คุณจะไม่สามารถเห็นผลลัพธ์ระดับกลางได้โดยใช้การตอบกลับ ในกรณีนี้ หลังจาก response.write เพิ่ม response.end ซึ่งมีประโยชน์สำหรับการดูผลลัพธ์ระดับกลาง
อย่างไรก็ตาม ถ้าคุณใช้เมธอด Response.End, Response.Redirect หรือ Server.Transfer ThreadAbortException จะเกิดขึ้น คุณสามารถตรวจจับข้อยกเว้นนี้ได้โดยใช้คำสั่ง try-catch
วิธีการ Response.End ยุติการดำเนินการของเพจ และสลับการดำเนินการเป็นเหตุการณ์ Application_EndRequest ในไปป์ไลน์เหตุการณ์ของแอปพลิเคชัน บรรทัดของโค้ดที่ตามหลัง Response.End จะไม่ถูกดำเนินการ
ปัญหานี้เกิดขึ้นในวิธีการ Response.Redirect และ Server.Transfer เนื่องจากทั้งสองวิธีเรียกภายใน Response.End
สารละลาย:
เมื่อต้องการแก้ไขปัญหานี้ ใช้วิธีใดวิธีหนึ่งต่อไปนี้:
• สำหรับ Response.End ให้เรียกเมธอด HttpContext.Current.ApplicationInstance.CompleteRequest แทน Response.End เพื่อข้ามการเรียกใช้โค้ดสำหรับเหตุการณ์ Application_EndRequest
• สำหรับ Response.Redirect ให้ใช้โอเวอร์โหลด Response.Redirect (String url, bool endResponse) ซึ่งส่งค่า false สำหรับพารามิเตอร์ endResponse เพื่อยกเลิกการเรียกภายในไปยัง Response.End ตัวอย่างเช่น:
Response.Redirect (Default.aspx, เท็จ);
การใช้งาน Response.End()
ในการพัฒนา ASP บางครั้งคุณอาจใช้ส่วนขนาดใหญ่ของการตัดสิน if...else อย่างไรก็ตาม หากเป็นเนื้อหา Response.write แบบไดนามิก และคุณต้องการทำให้อ่านโค้ดได้ง่ายขึ้น คุณสามารถใช้ Response.End() เพื่อ ยุติการดำเนินการของ ASP ซึ่งจะคล้ายกับการใช้ Break เช่น:
if (userid=)or(password=) แล้ว Response.Write() Response.End() 'นี่คือจุดสิ้นสุดของการขัดจังหวะหาก ต่อไปนี้เป็นการดำเนินการในการอ่านฐานข้อมูลหากไม่ว่างเปล่า โดยละเว้นโค้ด n บรรทัด
ด้วยวิธีนี้ เมื่อชื่อผู้ใช้หรือรหัสผ่านที่เข้ามาว่างเปล่า ข้อมูลพร้อมท์จะถูกเขียนโดยอัตโนมัติ จากนั้น Response.End() จะขัดจังหวะโปรแกรมเพื่อไปถึง if - - บทบาทของคนอื่น.
นอกจากนี้เวลาใช้งาน Response.End ก็คือเวลาที่เราทำการ Debug โปรแกรมทุกวัน เช่น
หากต้องการส่งออกคำสั่ง spliced SQL โดยไม่ต้องรันโค้ดต่อไปนี้ คุณสามารถทำได้
sql=select * จาก userinfo response.Write(sql)response.End()rs.open sql ,conn,1,1 'ประโยคนี้จะไม่ถูกดำเนินการ
หากคุณกลัวว่าจะเพิ่ม Response.End() มากเกินไป และไม่สะดวกที่จะแสดงความคิดเห็นเมื่อมีการเปิดตัวอย่างเป็นทางการ คุณสามารถสรุปมันด้วยฟังก์ชัน เช่น โค้ดต่อไปนี้:
ดีบักย่อย () Response.End () สิ้นสุดย่อย
รหัสข้างต้นได้รับการแก้ไขดังนี้:
sql=select * จาก userinfo response.Write(sql)debug()rs.open sql ,conn,1,1 'ประโยคนี้จะไม่ถูกดำเนินการ
ด้วยวิธีนี้ เมื่อมีการเปิดตัวอย่างเป็นทางการ การแสดงความคิดเห็นในคำสั่งฟังก์ชัน debug อาจมีบทบาทในการดีบักได้ อย่างไรก็ตาม ก็มีปัญหาเช่นกัน หากคุณใช้ debug() มากเกินไป โปรแกรมอาจไม่สามารถทำได้ ปฏิบัติตามคำแนะนำในระหว่างการดีบัก บางครั้งคุณไม่ต้องการให้การดำเนินการถูกขัดจังหวะในตำแหน่งเหล่านี้ ดังนั้นเรามาสร้างฟังก์ชัน debug() ใหม่กันดีกว่า ดังนี้:
sub debug(isBreak) 'isBreak เป็นพารามิเตอร์ที่มีค่าบูลีน หากตั้งค่าเป็นจริง จะขัดจังหวะการประมวลผลย่อย
รหัสเมื่อใช้มีดังนี้:
sql=select * จาก userinfo response.Write(sql)debug(false)rs.open sql ,conn,1,1 'ประโยคนี้จะถูกดำเนินการ rs.close()sql=select * จาก product response.write(sql) debug (true)rs.open sql,conn,1,1 'ประโยคนี้จะไม่ถูกดำเนินการ'
โอเค โดยพื้นฐานแล้วสิ่งนี้สามารถสนองความต้องการของเราในการควบคุมการขัดจังหวะได้ แต่เป็นเพียงการวิเคราะห์ง่ายๆ เท่านั้น จริงๆ แล้ว มันยังไม่สมบูรณ์มาก อาจมีข้อกำหนดการดีบักอีกมากมายที่จำเป็นต้องปฏิบัติตามและจำเป็นต้องสร้างใหม่เพิ่มเติม ที่จริงแล้ว การพัฒนาโปรแกรมเป็นกระบวนการของการรีแฟคเตอร์ การรีแฟคเตอร์ และการรีแฟคเตอร์ มิฉะนั้น จะมีรูปแบบการออกแบบมากมาย