فهم الأخطاء والتعامل معها

للتعامل مع الأخطاء بشكل فعال، من الضروري فهم أنواع الأخطاء التي يمكن أن تحدث. لنبدأ بتصنيف الأخطاء التي قد تواجهها.

أنواع الأخطاء في بيئة عميل الويب

أخطاء الشبكة

• مشكلات الاتصال: مشاكل في إنشاء اتصال بالخادم.
• المهلات: تستغرق الطلبات وقتًا طويلاً لتلقي الرد.
• أخطاء DNS: مشاكل في تحليل اسم النطاق.
• أخطاء HTTP: أخطاء مثل لم يتم العثور على 404، و500 خطأ داخلي في الخادم، وما إلى ذلك.

أخطاء واجهة برمجة تطبيقات الخادم

• ردود غير صالحة: بيانات غير متوقعة أو مشوهة من الخادم.
• أخطاء المصادقة: مشكلات تتعلق بمصادقة المستخدم أو ترخيصه.
• حدود المعدل: القيود بسبب تجاوز حدود استخدام واجهة برمجة التطبيقات.

أخطاء بيئة متصفح المستخدم

• توافق المتصفح: المشكلات الناشئة عن الاختلافات في كيفية تعامل المتصفحات مع ميزات معينة.
• أخطاء جافا سكريبت: أخطاء في كود جافا سكريبت من جانب العميل.
• أخطاء تحميل الموارد: مشاكل في تحميل الموارد مثل الصور أو البرامج النصية أو أوراق الأنماط.

أخطاء أخرى

• أخطاء من جانب العميل: الأخطاء المتعلقة بجهاز المستخدم أو نظام التشغيل.
• أخطاء واجهة المستخدم/تجربة المستخدم: مشكلات في واجهة المستخدم أو تجربة المستخدم، مثل الروابط المعطلة أو التخطيط غير الصحيح.

يمكن أن تحدث أنواع مختلفة من الأخطاء. ومع ذلك، يمكن تصنيف هذه الأخطاء عمومًا إلى فئتين:

1. الأخطاء المتوقعة: الأخطاء التي يكون حدوثها وطبيعتها معروفين مسبقًا.
2. أخطاء غير متوقعة: أخطاء لا يكون حدوثها وطبيعتها معروفين مسبقًا.

دعونا نقوم بتصنيف الأخطاء التي ناقشناها في هذه التصنيفات.

هل يمكن توقع الخطأ أم لا؟

الأخطاء المتوقعة

يمكن اعتبار الأخطاء المستلمة من واجهات برمجة تطبيقات الخادم ذات رموز الحالة الواضحة أخطاء متوقعة لأنه يمكن توقعها ومعالجتها مسبقًا.

على سبيل المثال، يمكن معالجة الأخطاء مثل الوصول غير المصرح به (401) أو الوصول المحظور (403) بشكل مناسب بناءً على الموقف. ومن الشائع أيضًا تحديد رموز خطأ أكثر تفصيلاً لكل رمز حالة لإدارة منطق التطبيق استجابةً للأخطاء. ويشار إلى هذه باسم الأخطاء المتوقعة.

أخطاء غير متوقعة

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

المستخدم والخطأ

يمكن أيضًا تصنيف الأخطاء بناءً على التفاعل مع المستخدم، وليس البيئة فقط. إحدى طرق تصنيف الأخطاء هي النظر فيما إذا كان بإمكان المستخدم فعل شيء حيال الخطأ. وفيما يلي معايير هذا التصنيف:

1. الأخطاء التي يمكن للمستخدم فهمها وحلها (الأخطاء التي تساعد المستخدم على الاستمرار في استخدام التطبيق).
2. الأخطاء التي لا يستطيع المستخدم حلها (الأخطاء التي لا تقدم أي مساعدة للمستخدم).

أخطاء قابلة للحل

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

إذا لم يكن لدى المستخدم إذن للوصول إلى شاشة معينة، فيمكنك إرشاده لطلب الوصول من المسؤول.

لا يوجد مطور منتج يرحب بتخلي المستخدم. من الضروري تقديم التوجيه للمستخدمين الذين يواجهون أخطاء لمساعدتهم في التغلب على الموقف. على سبيل المثال، توفير زر تحديث لأخطاء الشبكة المؤقتة أو زر للانتقال مرة أخرى إلى الشاشة السابقة عند الوصول إلى صفحة غير موجودة.

أخطاء غير قابلة للحل

ومع ذلك، هناك حالات لا يساعد فيها إبلاغ المستخدم بحالة الخطأ على الإطلاق. على سبيل المثال، إذا كانت التعليمات البرمجية تتضمن مكونات لا تعمل على أجهزة أو متصفحات منخفضة المواصفات، فلن يتمكن المستخدم من فعل أي شيء حيال ذلك. (ربما رسالة تقترح استخدام متصفح مختلف؟)

تتضمن الحالتان 1 و2 تقديم رسالة. الفرق هو أن الحالة 1 تتضمن بعض الإجراءات أو الإرشادات التي تطالب المستخدم باتخاذ الخطوات.

هل الخطأ الذي تم مواجهته هو شيء يمكن للمستخدم حله بنفسه أم لا؟

كيفية التعامل مع الأخطاء

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

أخطاء لا يمكن التنبؤ بها ولكن قابلة للحل

المثال النموذجي هو خطأ في الشبكة. يمكن أن يحدث هذا في أي وقت حسب بيئة الشبكة الخاصة بالمستخدم. الحل الأبسط هو إعلام المستخدم بأن هذا "خطأ مؤقت" وتقديم إرشادات لإعادة محاولة الإجراء السابق.

نطاق الخطأ

بالنسبة لهذه الأخطاء، من المهم التأكد من عدم تأثر التطبيق ككل سلبًا. على سبيل المثال، إذا قام أحد التطبيقات باستدعاء 10 واجهات برمجة تطبيقات على شاشة واحدة، فإن الفشل في إحداها لا ينبغي أن يؤدي إلى ظهور رسالة خطأ عبر التطبيق بأكمله ويتطلب إعادة محاولة جميع الاستدعاءات.

بدلاً من ذلك، ركز على استعادة المنطقة التي فشلت فقط.

أخطاء غير متوقعة وغير قابلة للحل

هذه أخطاء يصعب توقعها وليس لها حل مباشر. يجب التقليل من مثل هذه الأخطاء أثناء التطوير، ويجب أن تكون هناك خطة للتعامل معها عند حدوثها. وبما أن المستخدمين لا يستطيعون حل هذه الأخطاء بأنفسهم، فقد يكون من الضروري توفير طريقة سهلة للاتصال بدعم العملاء.

يراقب

يجب مراقبة الأخطاء الخارجة عن سيطرة المطور باستخدام أدوات مثل Sentry. يجب إصلاح هذه الأخطاء لمنع المستخدمين من مواجهتها. بالإضافة إلى ذلك، تأكد من وجود آلية للمستخدمين للعودة إلى التطبيق إذا واجهوا مثل هذه الأخطاء.

أخطاء يمكن التنبؤ بها ولكن لا يمكن حلها

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

الأخطاء المتعلقة بالأمان

تحدث هذه الأخطاء عندما تكون هناك نية خبيثة لاستغلال التطبيق. تنبع عادةً من ثغرات أمنية ويجب منعها أثناء التطوير. من الضروري معالجة المخاوف الأمنية الأساسية مثل CORS وXSS والتعاون مع فريق الأمان لإنشاء تطبيق آمن.

أخطاء يمكن التنبؤ بها وقابلة للحل

عادةً ما تكون هذه الأخطاء جزءًا من منطق العمل الذي يعرفه المطورون بالفعل:

• 401 خطأ غير مصرح به: يتطلب تسجيل الدخول.
• خطأ 404 لم يتم العثور عليه: الوصول إلى صفحة خاطئة.
• أخطاء منطق الأعمال الأخرى: يتم تحديدها بواسطة منطق التطبيق.

في هذه الحالات، قم بتوفير التوجيه المناسب داخل التطبيق أو قم بإنشاء صفحات منفصلة لتوجيه المستخدمين.

أهمية التوجيه

يجب على المستخدمين أن يفهموا بوضوح ما يجب فعله بعد ظهور رسالة خطأ. وهذا يساعد على تقليل تكرار الأخطاء ويمنع هجر المستخدم. لذلك، إلى جانب رسالة الخطأ، من الضروري تضمين عبارة تحث المستخدم على اتخاذ إجراء.

على سبيل المثال، إذا كان هناك خطأ في التحقق من صحة الحقل، فقم بالتركيز على الحقل الذي حدث فيه الخطأ. إذا انتقل المستخدم إلى صفحة غير موجودة، فقم بتوفير زر للعودة إلى الشاشة السابقة.

خاتمة

لقد اكتشفنا معالجة الأخطاء. دعونا ندير الأخطاء بكفاءة من خلال استخدام الأدوات والتقنيات المتنوعة مثل أدوات مراقبة الأخطاء وReact's ErrorBoundary، والتي يمكنها اكتشاف الأخطاء ضمن نطاق محدود.