سواء في asp أو asp.net، يقوم Response.end بإنهاء محتوى الإخراج ويستخدم في الغالب لتصحيح أخطاء البرامج، كما أنه مفيد جدًا، على غرار تعيين نقاط التوقف، خاصة عندما يواجه برنامجك مشكلات كبيرة، مثل حلقة الاستجابة اللانهائية. لا يمكن للكتابة رؤية النتائج المتوسطة، وفي هذه الحالة، قم بإضافة Response.end بعد Response.write، وهذا مفيد جدًا لعرض النتائج المتوسطة.
أولا دعونا نتحدث عن فوائده.
كما أنه مفيد جدًا عند تصحيح أخطاء أحد البرامج، وهو مشابه لتعيين نقاط التوقف، خاصةً إذا كان برنامجك يعاني من مشكلات كبيرة. على سبيل المثال، عندما يكون هناك حلقة لا نهائية، لا يمكن رؤية النتائج الوسيطة باستخدام Response.write ، بعد Response.write أضف Response.end، وهو أمر مفيد لعرض النتائج المتوسطة.
ومع ذلك، إذا كنت تستخدم أسلوب Response.End، أو Response.Redirect، أو Server.Transfer، فسيحدث ThreadAbortException. يمكنك التقاط هذا الاستثناء باستخدام عبارة حاول الالتقاط.
ينهي الأسلوب 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, false);
استخدام Response.End()
في تطوير ASP، يمكنك أحيانًا استخدام أقسام كبيرة من أحكام if...else، ومع ذلك، إذا كان محتوى Response.write ديناميكيًا وتريد تسهيل قراءة التعليمات البرمجية، فيمكنك استخدام Response.End(). إنهاء تنفيذ ASP وهو مشابه لاستخدام Break، على سبيل المثال:
إذا (userid=)or(password=) ثم Response.Write() Response.End() 'هنا نهاية المقاطعة إذا كان ما يلي هو عملية قراءة قاعدة البيانات إذا لم تكن فارغة، مع حذف n من أسطر التعليمات البرمجية
بهذه الطريقة، عندما يكون اسم المستخدم أو كلمة المرور الواردة فارغة، تتم كتابة معلومات المطالبة تلقائيًا، ثم يقوم Response.End() بمقاطعة البرنامج للوصول إلى if. . . دور غيره.
بالإضافة إلى ذلك، عند استخدام Response.End، يتم ذلك عندما نقوم بتصحيح أخطاء البرنامج يوميًا، مثل
لإخراج عبارة SQL المقسمة دون تنفيذ التعليمات البرمجية التالية، يمكنك القيام بذلك
sql=select * from userinfo Response.Write(sql)response.End()rs.open sql ,conn,1,1 'لن يتم تنفيذ هذه الجملة
إذا كنت تخشى أن يكون هناك الكثير من الأماكن لإضافة Response.End() ولن يكون من السهل التعليق عليها عندما يتم إصدارها رسميًا، فيمكنك تغليفها بوظيفة، مثل التعليمة البرمجية التالية:
التصحيح الفرعي() Response.End()end sub
يتم تعديل الكود أعلاه على النحو التالي:
sql=select * from userinfo Response.Write(sql)debug()rs.open sql ,conn,1,1 'لن يتم تنفيذ هذه الجملة
بهذه الطريقة، عندما يتم إصدارها رسميًا، يمكن أن يلعب التعليق على العبارات الموجودة في وظيفة تصحيح الأخطاء دورًا تصحيحيًا، ومع ذلك، هناك أيضًا مشكلة في هذا إذا كنت تستخدم عددًا كبيرًا جدًا من debug()، فقد لا يتمكن البرنامج من القيام بذلك اتبع الإرشادات أثناء تصحيح الأخطاء. في بعض الأحيان لا ترغب في مقاطعة التنفيذ في هذه الأماكن، لذلك دعونا نعيد بناء وظيفة debug()، كما يلي:
sub debug(isBreak) 'isBreak هي معلمة ذات قيمة منطقية إذا تم تعيينها على true، فسيتم مقاطعتها. وإلا، لن يتم تنفيذ معالجة المقاطعة إذا كانت isBreak ثم Response.End() endend sub
الكود عند استخدامه هو كما يلي:
sql=select * from userinfo Response.Write(sql)debug(false)rs.open sql ,conn,1,1 'سيتم تنفيذ هذه الجملة rs. Close()sql=select * من المنتج Response.write(sql) debug (صحيح)rs.open sql,conn,1,1 'لن يتم تنفيذ هذه الجملة
حسنًا، يمكن أن يلبي هذا بشكل أساسي حاجتنا للتحكم في المقاطعات، ولكنه في الواقع مجرد تحليل غير كامل للغاية. قد يكون هناك العديد من متطلبات التصحيح التي يجب تلبيتها ويلزم إجراء المزيد من إعادة البناء. في الواقع، تطوير البرنامج هو عملية إعادة هيكلة، وإعادة هيكلة، وإعادة هيكلة، وإلا فسيكون هناك الكثير من أنماط التصميم، وهي كلها تجارب لخصها أسلافهم من عملية التطوير وإعادة الهيكلة الفعلية، وهي تستحق التعلم منها.