آلية معالجة أخطاء ASP.NET

بالنسبة لتطبيقات الويب، الأخطاء أمر لا مفر منه، لذا يجب علينا اتخاذ الاحتياطات اللازمة وتوفير المعالجة المناسبة للأخطاء المحتملة. في الواقع، تعد آلية التعامل الجيدة مع الأخطاء معيارًا مهمًا لقياس جودة تطبيقات الويب. فقط تخيل، عندما يقوم المستخدم عن طريق الخطأ بإدخال عنوان URL خاطئ في المتصفح أو عندما يقدم المستخدم بعض المعلومات التي تتسبب في حدوث خطأ في البرنامج، إذا لم نتعامل مع هذه المواقف، فإننا نسمح بـ 404 أو 500 صفحة خطأ أو حتى معلومات المكدس يتم تقديمه أمام المستخدمين، الأمر الذي سيخيف بعض المستخدمين بلا شك. لذلك، عندما نقوم بتطوير تطبيقات الويب، يجب أن يكون لدينا فهم كامل لآلية معالجة الأخطاء.

دعنا نعود إلى ASP.NET ونطرح سؤالين ليفكر الجميع فيهما: ما عدد آليات معالجة الأخطاء التي يوفرها لنا ASP.NET؟ إذا تم استخدام عدة آليات لمعالجة الأخطاء في نفس الوقت، فهل هناك أولوية معينة بينها؟ مع وضع هذا السؤال في الاعتبار، دعونا أولاً نلقي نظرة على ملف Web.Config الأكثر شيوعًا لدينا:

<التكوين>


<خطأ كود الحالة = "403" إعادة التوجيه = "Error403.htm" />
<خطأ كود الحالة = "404" إعادة توجيه = "Error404.htm" />

فيما يتعلق بعنصر الإعداد ، أعتقد أنه ليست هناك حاجة لقول المزيد للحصول على التفاصيل، يرجى الرجوع إلى MSDN. آلية معالجة الأخطاء الأولى - استخدام عنصر التكوين الخاص بـ Web.Config يجب أن تكون الأكثر استخدامًا.
بعد ذلك، دعونا نلقي نظرة على ملف آخر شائع الاستخدام أيضًا: Global.asax. عندما تذكر هذه الوثيقة، ما رأيك؟ نعم، إنها أحداث مرتبطة بعنصرين رئيسيين في تطبيق الويب (التطبيق والجلسة). من بين هذه الأحداث، هناك حدث متعلق بالخطأ ينتمي إلى فئة التطبيق - خطأ، وطريقة معالجة الحدث المقابلة هي Application_Error. كما يوحي الاسم، سيتم استدعاء طريقة معالجة الحدث هذه عند حدوث خطأ على مستوى التطبيق، بحيث يمكنك إضافة تعليمات برمجية في هذه الطريقة لمعالجة الخطأ، كما هو موضح أدناه:

protected void Application_Error(object sender, EventArgs e) {
استثناء objErr = Server.GetLastError().GetBaseException();
Response.Write("خطأ:" + objErr.Message);
Server.ClearError();
}

هنا يجب على الجميع الانتباه إلى استخدام Server.ClearError() في السطر الأخير من التعليمات البرمجية. لماذا يجب استخدام هذا السطر من التعليمات البرمجية؟ ماذا يحدث إذا لم تستخدمه؟ وهنا سأحاول مرة أخرى. حسنًا، الآلية الثانية لمعالجة الأخطاء - استخدام طريقة معالجة الأحداث Application_Error في Global.asax ظهرت أيضًا لأول مرة.

يمكن القول بأن الطريقتين المذكورتين أعلاه لمعالجة الأخطاء هما طريقتان عموميتان، إحداهما مشتقة من ملف تكوين التطبيق، والأخرى هي طريقة معالجة الأحداث الخاصة بالملف Global.asax الذي يجب وضعه في الدليل الجذر للتطبيق. وعكس العالمي هو المحلي، لذا بطبيعة الحال نتساءل: هل هناك آلية لمعالجة الأخطاء تنطبق على المحلي - صفحة معينة؟ الإجابة هي "نعم"، وهناك طريقتان - استخدام سمة ErrorPage واستخدام أسلوب التعامل مع الأحداث Page_Error. بالنسبة للآلية الأولى، يمكنك تعيين خاصية ErrorPage في أي وقت تقريبًا لتحديد الصفحة التي سيتم إعادة التوجيه إليها عند حدوث خطأ في الصفحة، أما بالنسبة للآلية الثانية، فهي تشبه إلى حد كبير طريقة معالجة الحدث Application_Error، باستثناء ذلك توقيت التشغيل مختلف. فيما يلي مثالان محددان:

Page_Error (مرسل الكائن، EventArgs e) { باطلة محمية
استثناء objErr = Server.GetLastError().GetBaseException();
Response.Write("خطأ:" + objErr.Message);
Server.ClearError(); // انتبه أيضًا إلى استخدام هذا الرمز
}

في هذه المرحلة، ظهرت جميع آليات معالجة الأخطاء الأربعة، وحان الوقت لتصنيفها. قم بالفرز من الأولوية العالية إلى المنخفضة: طريقة معالجة الحدث Page_Error > خاصية ErrorPage > طريقة معالجة الحدث Application_Error > عنصر التكوين . على الرغم من أن الترتيب على هذا النحو، إلا أن هناك علاقة دقيقة بين التصنيفات. أولاً، لكي تعمل سمة ErrorPage، يجب تعيين سمة الوضع في عنصر التكوين على "تشغيل" ثانيًا، على الرغم من أن طريقة معالجة الأحداث Page_Error تأتي في المرتبة الأولى، إذا كانت طريقة Server.ClearError() هي مفقود إذا كان الأمر كذلك، فسيستمر تشغيل معالجة الأخطاء ذات الأولوية المنخفضة. وينطبق هذا أيضًا على أسلوب معالجة الأحداث Application_Error. تم ترتيب الترتيب، لكن الترتيب ليس هو القضية الأكثر أهمية، بل يمكن القول إنها مسألة ليس لها معنى كبير، لأنه في كثير من الحالات، قد لا تخلط بين آليات المعالجة الأربعة هذه. أعتقد أن القضية الأكثر أهمية هي كيفية اختيار آليات معالجة الأخطاء هذه. بخصوص هذا الموضوع، أتمنى من الأصدقاء ذوي الخبرة أن يشاركوا بآرائهم.

حسنًا، هذا هو تقديم آليات التعامل مع الأخطاء الأربعة في ASP.NET، وحان الوقت للحديث عن بعض مشاعري الخاصة. لقد قام مصممو ASP.NET بالفعل بوضع اعتبارات شاملة من وجهة نظر المطورين، لذا فهم يقدمون لنا ما يصل إلى أربع آليات لمعالجة الأخطاء لنختار من بينها، وهو أمر يستحق الثناء. ولكن لإعادة صياغة شعار إعلاني - الكثير من الأمور مربكة، وسنشعر أيضًا بالدوار قليلاً بسبب وجود الكثير من آليات معالجة الأخطاء. بمقارنة معالجة الأخطاء في مجال J2EE، يمكننا أن نجد أن الأمر بسيط نسبيًا. الأول هو الإعداد المطابق لـ ، ويمكننا أيضًا العثور على عناصر تكوين مماثلة من ملف web.xml الأكثر استخدامًا في مشاريع J2EE: ؛ ثانيًا، في مجال J2EE، الصفحة ليست كيانًا مهمًا و الحدث نموذج برنامج التشغيل ليس ضروريًا، لذلك لا يمكنني حقًا العثور على آلية المعالجة المقابلة لطريقتي Application_Error وPage_Error؛ وأخيرًا، في مجال J2EE، يتم التركيز بشكل أكبر على الطلب والاستجابة بمجرد حدوث خطأ في المعالجة المنطقية ، يمكننا بسهولة توزيع الطلب على وحدة معالجة الأخطاء المقابلة من خلال RequestDispatcher. في الواقع، هذه طريقة معالجة مرنة للغاية قد يرغب الأصدقاء المهتمون في التعرف عليها.