دليل نهائي لمعالجة الأخطاء في JavaScript

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

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

إذا كنت تقوم ببناء تطبيق JavaScript ، فهناك احتمال كبير بأن تفسد أنواع البيانات في وقت أو آخر. إذا لم يكن الأمر كذلك ، فقد ينتهي بك الأمر باستبدال عامل غير محدد بعامل فارغ أو ثلاثي يساوي ( === ) مع عامل يساوي مزدوج ( == ).

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

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

بدون مزيد من اللغط ، لنبدأ!

ما هي أخطاء JavaScript؟

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

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

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

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

خصائص الخطأ

الآن بعد أن أصبح تعريف خطأ JavaScript واضحًا ، حان الوقت للتعمق في التفاصيل.

تتضمن الأخطاء في JavaScript خصائص قياسية ومخصصة معينة تساعد في فهم سبب الخطأ وتأثيراته. تحتوي الأخطاء في JavaScript افتراضيًا على ثلاث خصائص:

1. message : قيمة سلسلة تحمل رسالة الخطأ
2. الاسم : نوع الخطأ الذي حدث (سنتعمق في هذا في القسم التالي)
3. المكدس : تم تنفيذ تتبع المكدس الخاص بالشفرة عند حدوث الخطأ.

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

فهم تتبع المكدس

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

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

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

الأخطاء مقابل الاستثناءات

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

لفهم هذا بشكل أفضل ، دعنا نأخذ مثالاً سريعًا. إليك كيفية تحديد خطأ في JavaScript:

 const wrongTypeError = TypeError("Wrong type found, expected character")

وهذه هي الطريقة التي wrongTypeError إلى استثناء:

 throw wrongTypeError

ومع ذلك ، يميل معظم الأشخاص إلى استخدام صيغة الاختزال التي تحدد كائنات الخطأ أثناء رميها:

 throw TypeError("Wrong type found, expected character")

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

أنواع الأخطاء في JavaScript

هناك مجموعة من أنواع الأخطاء المحددة مسبقًا في JavaScript. يتم اختيارهم وتعريفهم تلقائيًا بواسطة وقت تشغيل JavaScript عندما لا يتعامل المبرمج بشكل صريح مع الأخطاء في التطبيق.

سيرشدك هذا القسم إلى بعض أكثر أنواع الأخطاء شيوعًا في JavaScript ويفهم متى ولماذا تحدث.

RangeError

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

بعض السيناريوهات الشائعة التي يحدث فيها RangeError هي:

• محاولة إنشاء مصفوفة من الأطوال غير القانونية عبر مُنشئ الصفيف.
• تمرير القيم السيئة إلى الطرق الرقمية مثل toExponential() و toPrecision() و toFixed() وما إلى ذلك.
• تمرير القيم غير القانونية إلى دوال السلسلة مثل normalize() .

المرجع خطأ

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

بعض الأسباب الشائعة لحدوث أخطاء المراجع هي:

• عمل خطأ مطبعي في اسم متغير.
• محاولة الوصول إلى متغيرات محددة النطاق خارج نطاقاتها.
• الرجوع إلى متغير عام من مكتبة خارجية (مثل $ من jQuery) قبل تحميله.

خطأ في بناء الجملة

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

بعض الأسباب الشائعة لحدوث أخطاء في بناء الجملة هي:

• الفواصل المقلوبة مفقودة
• أقواس الإغلاق مفقودة
• المحاذاة غير الصحيحة للأقواس المتعرجة أو الأحرف الأخرى

من الممارسات الجيدة استخدام أداة الفحص في IDE الخاص بك لتحديد مثل هذه الأخطاء لك قبل أن تصل إلى المتصفح.

خطأ مطبعي

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

• استدعاء الأشياء التي ليست أساليب.
• محاولة الوصول إلى خصائص كائنات فارغة أو غير محددة
• معاملة السلسلة كرقم أو العكس

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

خطأ داخلي

يتم استخدام نوع InternalError عند حدوث استثناء في محرك وقت تشغيل JavaScript. قد يشير أو لا يشير إلى مشكلة في التعليمات البرمجية الخاصة بك.

في أغلب الأحيان ، يحدث الخطأ الداخلي في سيناريوهين فقط:

• عندما يحمل تصحيح أو تحديث لوقت تشغيل JavaScript خطأً يؤدي إلى استثناءات (نادرًا ما يحدث هذا)
• عندما تحتوي التعليمات البرمجية الخاصة بك على كيانات كبيرة جدًا بالنسبة لمحرك JavaScript (على سبيل المثال ، عدد كبير جدًا من حالات التبديل ، ومُبدِلات الصفيف الكبيرة جدًا ، والكثير من العودية)

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

URIError

يحدث خطأ URIE عند استخدام دالة معالجة URI عالمية مثل decodeURIComponent بشكل غير قانوني. يشير عادةً إلى أن المعلمة التي تم تمريرها إلى استدعاء الأسلوب لا تتوافق مع معايير URI وبالتالي لم يتم تحليلها بواسطة الطريقة بشكل صحيح.

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

EvalError

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

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

إنشاء أنواع أخطاء مخصصة

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

لذلك ، من الناحية الفنية ، فإن هذه البيانات قانونية تمامًا:

 throw 8 throw "An error occurred"

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

يمكنك توسيع فئة Error لإنشاء فئة الخطأ المخصصة الخاصة بك. فيما يلي مثال أساسي لكيفية القيام بذلك:

 class ValidationError extends Error { constructor(message) { super(message); this.name = "ValidationError"; } }

ويمكنك استخدامه بالطريقة التالية:

 throw ValidationError("Property not found: name")

ويمكنك بعد ذلك تحديدها باستخدام instanceof الكلمة الرئيسية:

 try { validateForm() // code that throws a ValidationError } catch (e) { if (e instanceof ValidationError) // do something else // do something else }

أهم 10 أخطاء شائعة في JavaScript

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

1. RangeError لم يتم اكتشافه

يحدث هذا الخطأ في Google Chrome في إطار عدة سيناريوهات مختلفة. أولاً ، يمكن أن يحدث ذلك إذا قمت باستدعاء دالة تكرارية ولم تنتهي. يمكنك التحقق من ذلك بنفسك في Chrome Developer Console:

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

ستشير رسالة الخطأ عادةً إلى الخطأ في الرمز الخاص بك. بمجرد إجراء التغييرات ، سيتم حلها.

2. خطأ في النوع غير معلوم: لا يمكن تعيين الخاصية

يحدث هذا الخطأ عند تعيين خاصية على مرجع غير محدد. يمكنك إعادة إظهار المشكلة بهذا الرمز:

 var list list.count = 0

هذا هو الناتج الذي ستحصل عليه:

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

3. خطأ في النوع غير معلوم: لا يمكن قراءة الخاصية

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

 var func func.call()

ها هو الناتج:

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

 import React, { useState, useEffect } from "react"; const CardsList = () => { const [state, setState] = useState(); useEffect(() => { setTimeout(() => setState({ items: ["Card 1", "Card 2"] }), 2000); }, []); return ( <> {state.items.map((item) => ( <li key={item}>{item}</li> ))} </> ); }; export default CardsList;

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

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

 // ... const [state, setState] = useState({items: []}); // ...

الآن ، بعد التأخير المحدد ، سيعرض تطبيقك ناتجًا مشابهًا:

قد يكون الإصلاح الدقيق في شفرتك مختلفًا ، لكن الجوهر هنا هو تهيئة المتغيرات الخاصة بك دائمًا بشكل صحيح قبل استخدامها.

4. TypeError: "undefined" ليس كائنًا

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

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

5. TypeError: null ليس كائنًا

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

 var func = null func.call()

هذا هو الناتج الذي ستحصل عليه:

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

6. TypeError: لا يمكن قراءة الخاصية 'length'

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

ومع ذلك ، في الإصدارات الأحدث من Chrome ، تم الإبلاغ عن هذا الخطأ على أنه Uncaught TypeError: Cannot read properties of undefined . هكذا تبدو الآن:

الإصلاح ، مرة أخرى ، هو التأكد من أن الكائن الذي تحاول الوصول إلى طوله موجود ولم يتم تعيينه على قيمة null .

7. TypeError: "undefined" ليست دالة

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

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

 function showAlert() { alert("message here") } document.addEventListener("click", () => { this.showAlert(); })

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

في المقابل ، يتم تعريف الوظيفة showAlert في سياق window .

لحل هذه المشكلة ، يجب عليك تمرير المرجع المناسب للوظيفة بربطها بطريقة bind() :

 document.addEventListener("click", this.showAlert.bind(this))

8. ReferenceError: لم يتم تعريف الحدث

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

قد لا يحدث هذا الخطأ في Internet Explorer أو Google Chrome (حيث يقدم IE متغير حدث عالميًا ويقوم Chrome بإرفاق متغير الحدث تلقائيًا بالمعالج) ، ولكن يمكن أن يحدث في Firefox. لذلك من المستحسن الانتباه لمثل هذه الأخطاء الصغيرة.

9. TypeError: التخصيص لمتغير ثابت

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

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

10. (غير معروف): خطأ في البرنامج النصي

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

لا يمكنك حل هذا الخطأ دون معرفة التفاصيل الكاملة. إليك ما يمكنك فعله للحصول على مزيد من المعلومات حول الخطأ:

1. أضف السمة crossorigin في علامة البرنامج النصي.
2. قم بتعيين رأس Access-Control-Allow-Origin الصحيح على الخادم الذي يستضيف البرنامج النصي.
3. [اختياري] إذا لم يكن لديك حق الوصول إلى الخادم الذي يستضيف النص البرمجي ، فيمكنك التفكير في استخدام وكيل لنقل طلبك إلى الخادم والعودة إلى العميل باستخدام الرؤوس الصحيحة.

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

كيفية تحديد ومنع الأخطاء في JavaScript

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

رمي الأخطاء يدويًا والتقاطها

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

رمي

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

• يمكنك throw أي شيء ، بما في ذلك الأرقام والسلاسل وكائنات Error .
• ومع ذلك ، لا يُنصح برمي أنواع البيانات الأولية مثل السلاسل والأرقام لأنها لا تحمل معلومات تصحيح الأخطاء حول الأخطاء.
• مثال: throw TypeError("Please provide a string")

محاولة

يتم استخدام الكلمة الأساسية try للإشارة إلى أن كتلة التعليمات البرمجية قد تؤدي إلى استثناء. تركيبها هو:

 try { // error-prone code here }

من المهم ملاحظة أن كتلة catch يجب أن تتبع دائمًا كتلة try للتعامل مع الأخطاء بشكل فعال.

امساك

يتم استخدام الكلمة الأساسية catch لإنشاء كتلة catch. هذه الكتلة من التعليمات البرمجية مسؤولة عن معالجة الأخطاء التي تلتقطها كتلة try اللاحقة. ها هو تركيبها:

 catch (exception) { // code to handle the exception here }

وهذه هي الطريقة التي تنفذ بها كتل try و catch معًا:

 try { // business logic code } catch (exception) { // error handling code }

بخلاف C ++ أو Java ، لا يمكنك إلحاق كتل catch متعددة بمجموعة try في JavaScript. هذا يعني أنه لا يمكنك القيام بذلك:

 try { // business logic code } catch (exception) { if (exception instanceof TypeError) { // do something } } catch (exception) { if (exception instanceof RangeError) { // do something } }

بدلاً من ذلك ، يمكنك استخدام عبارة if...else أو بيان حالة التبديل داخل كتلة catch المفردة للتعامل مع جميع حالات الخطأ المحتملة. انها تبدو مثل هذا:

 try { // business logic code } catch (exception) { if (exception instanceof TypeError) { // do something } else if (exception instanceof RangeError) { // do something else } }

أخيرا

يتم استخدام الكلمة الأساسية في finally لتحديد كتلة التعليمات البرمجية التي يتم تشغيلها بعد معالجة الخطأ. يتم تنفيذ هذه الكتلة بعد كتل try و catch.

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

لكي يتم اعتباره صالحًا ، يجب أن يتبع كتلة try في JavaScript إما كتلة catch أو block. بدون أي من هؤلاء ، سيرفع المترجم خطأ نحوي. لذلك ، تأكد من اتباع كتل المحاولة الخاصة بك مع أي منهما على الأقل عند معالجة الأخطاء.

معالجة الأخطاء بشكل عام باستخدام أسلوب onerror ()

طريقة onerror() متاحة لجميع عناصر HTML لمعالجة أي أخطاء قد تحدث معهم. على سبيل المثال ، إذا لم تتمكن علامة img من العثور على الصورة التي تم تحديد عنوان URL الخاص بها ، فإنها تطلق طريقة on Error للسماح للمستخدم بمعالجة الخطأ.

عادةً ، يمكنك تقديم عنوان URL آخر للصورة في استدعاء عند حدوث خطأ لعلامة img للرجوع إليه. هذه هي الطريقة التي يمكنك بها القيام بذلك عبر JavaScript:

 const image = document.querySelector("img") image.onerror = (event) => { console.log("Error occurred: " + event) }

ومع ذلك ، يمكنك استخدام هذه الميزة لإنشاء آلية عالمية لمعالجة الأخطاء لتطبيقك. إليك كيف يمكنك القيام بذلك:

 window.onerror = (event) => { console.log("Error occurred: " + event) }

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

تمرير الأخطاء عبر عمليات الاسترجاعات

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

ضع في اعتبارك الجزء التالي من الكود:

 const calculateCube = (number, callback) => { setTimeout(() => { const cube = number * number * number callback(cube) }, 1000) } const callback = result => console.log(result) calculateCube(4, callback)

توضح الوظيفة أعلاه حالة غير متزامنة تستغرق فيها الوظيفة بعض الوقت لمعالجة العمليات وإرجاع النتيجة لاحقًا بمساعدة رد الاتصال.

إذا حاولت إدخال سلسلة بدلاً من 4 في استدعاء الوظيفة ، فستحصل على NaN نتيجة لذلك.

هذا يحتاج إلى التعامل معه بشكل صحيح. إليك الطريقة:

 const calculateCube = (number, callback) => { setTimeout(() => { if (typeof number !== "number") throw new Error("Numeric argument is expected") const cube = number * number * number callback(cube) }, 1000) } const callback = result => console.log(result) try { calculateCube(4, callback) } catch (e) { console.log(e) }

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

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

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

إليك كيفية التعامل مع الأخطاء بشكل صحيح في عمليات الاسترجاعات:

 const calculateCube = (number, callback) => { setTimeout(() => { if (typeof number !== "number") { callback(new TypeError("Numeric argument is expected")) return } const cube = number * number * number callback(null, cube) }, 2000) } const callback = (error, result) => { if (error !== null) { console.log(error) return } console.log(result) } try { calculateCube('hey', callback) } catch (e) { console.log(e) }

الآن ، سيكون الإخراج في وحدة التحكم:

يشير هذا إلى أنه تم معالجة الخطأ بشكل مناسب.

معالجة الأخطاء في الوعود

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

 const delay = ms => new Promise(res => setTimeout(res, ms)); const calculateCube = async (number) => { if (typeof number !== "number") throw Error("Numeric argument is expected") await delay(5000) const cube = number * number * number return cube } try { calculateCube(4).then(r => console.log(r)) } catch (e) { console.log(e) }

تم عزل المهلة من الكود السابق في وظيفة delay لفهمها. إذا حاولت إدخال سلسلة بدلاً من 4 ، فسيكون الإخراج الذي تحصل عليه مماثلاً لما يلي:

مرة أخرى ، هذا بسبب Promise الذي ألقى بالخطأ بعد أن يتم تنفيذ كل شيء آخر. حل هذه المشكلة بسيط. ما عليك سوى إضافة أمر catch() إلى سلسلة الوعد مثل هذا:

 calculateCube("hey") .then(r => console.log(r)) .catch(e => console.log(e))

الآن سيكون الإخراج:

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

بدلاً من ذلك ، يمكنك أيضًا التعامل مع الأخطاء في الوعود باستخدام تقنية try-catch-finally التقليدية. إليك كيف ستبدو مكالمة الوعد في هذه الحالة:

 try { let result = await calculateCube("hey") console.log(result) } catch (e) { console.log(e) } finally { console.log('Finally executed") }

ومع ذلك ، يعمل هذا داخل وظيفة غير متزامنة فقط. لذلك فإن الطريقة الأكثر تفضيلاً للتعامل مع الأخطاء في الوعود هي سلسلة catch finally إلى استدعاء الوعد.

رمي / إمساك مقابل خطأ () مقابل الاسترجاعات مقابل الوعود: أيهما أفضل؟

مع وجود أربع طرق تحت تصرفك ، يجب أن تعرف كيفية اختيار الأنسب في أي حالة استخدام معينة. إليك كيف يمكنك أن تقرر بنفسك:

رمي / قبض

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

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

عند الاختيار بين كتل المحاولة / الالتقاط غير المتزامنة والقبض على الوعد catch() ، يُنصح باستخدام كتل المحاولة / الالتقاط غير المتزامنة لأنها ستجعل الكود الخاص بك خطيًا ويسهل تصحيحه.

على خطأ ()

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

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

الاسترجاعات والوعود

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

هذا لأن الوعود لها بنية مضمنة لتسلسل catch() finally() وكتلة أخيرة () للتعامل مع الأخطاء بسهولة. This method is easier and cleaner than defining additional arguments/reusing existing arguments to handle errors.

Keep Track of Changes With Git Repositories

Many errors often arise due to manual mistakes in the codebase. While developing or debugging your code, you might end up making unnecessary changes that may cause new errors to appear in your codebase. Automated testing is a great way to keep your code in check after every change. However, it can only tell you if something's wrong. If you don't take frequent backups of your code, you'll end up wasting time trying to fix a function or a script that was working just fine before.

This is where git plays its role. With a proper commit strategy, you can use your git history as a backup system to view your code as it evolved through the development. You can easily browse through your older commits and find out the version of the function working fine before but throwing errors after an unrelated change.

You can then restore the old code or compare the two versions to determine what went wrong. Modern web development tools like GitHub Desktop or GitKraken help you to visualize these changes side by side and figure out the mistakes quickly.

A habit that can help you make fewer errors is running code reviews whenever you make a significant change to your code. If you're working in a team, you can create a pull request and have a team member review it thoroughly. This will help you use a second pair of eyes to spot out any errors that might have slipped by you.

Best Practices for Handling Errors in JavaScript

The above-mentioned methods are adequate to help you design a robust error handling approach for your next JavaScript application. However, it would be best to keep a few things in mind while implementing them to get the best out of your error-proofing. Here are some tips to help you.

1. Use Custom Errors When Handling Operational Exceptions

We introduced custom errors early in this guide to give you an idea of how to customize the error handling to your application's unique case. It's advisable to use custom errors wherever possible instead of the generic Error class as it provides more contextual information to the calling environment about the error.

On top of that, custom errors allow you to moderate how an error is displayed to the calling environment. This means that you can choose to hide specific details or display additional information about the error as and when you wish.

You can go so far as to format the error contents according to your needs. This gives you better control over how the error is interpreted and handled.

2. Do Not Swallow Any Exceptions

Even the most senior developers often make a rookie mistake — consuming exceptions levels deep down in their code.

You might come across situations where you have a piece of code that is optional to run. If it works, great; if it doesn't, you don't need to do anything about it.

In these cases, it's often tempting to put this code in a try block and attach an empty catch block to it. However, by doing this, you'll leave that piece of code open to causing any kind of error and getting away with it. This can become dangerous if you have a large codebase and many instances of such poor error management constructs.

The best way to handle exceptions is to determine a level on which all of them will be dealt and raise them until there. This level can be a controller (in an MVC architecture app) or a middleware (in a traditional server-oriented app).

This way, you'll get to know where you can find all the errors occurring in your app and choose how to resolve them, even if it means not doing anything about them.

3. Use a Centralized Strategy for Logs and Error Alerts

Logging an error is often an integral part of handling it. Those who fail to develop a centralized strategy for logging errors may miss out on valuable information about their app's usage.

An app's event logs can help you figure out crucial data about errors and help to debug them quickly. If you have proper alerting mechanisms set up in your app, you can know when an error occurs in your app before it reaches a large section of your user base.

It's advisable to use a pre-built logger or create one to suit your needs. You can configure this logger to handle errors based on their levels (warning, debug, info, etc.), and some loggers even go so far as to send logs to remote logging servers immediately. This way, you can watch how your application's logic performs with active users.

4. Notify Users About Errors Appropriately

Another good point to keep in mind while defining your error handling strategy is to keep the user in mind.

All errors that interfere with the normal functioning of your app must present a visible alert to the user to notify them that something went wrong so the user can try to work out a solution. If you know a quick fix for the error, such as retrying an operation or logging out and logging back in, make sure to mention it in the alert to help fix the user experience in real-time.

In the case of errors that don't cause any interference with the everyday user experience, you can consider suppressing the alert and logging the error to a remote server for resolving later.

5. Implement a Middleware (Node.js)

The Node.js environment supports middlewares to add functionalities to server applications. You can use this feature to create an error-handling middleware for your server.

The most significant benefit of using middleware is that all of your errors are handled centrally in one place. You can choose to enable/disable this setup for testing purposes easily.

Here's how you can create a basic middleware:

const logError = err => { console.log("ERROR: " + String(err)) } const errorLoggerMiddleware = (err, req, res, next) => { logError(err) next(err) } const returnErrorMiddleware = (err, req, res, next) => { res.status(err.statusCode || 500) .send(err.message) } module.exports = { logError, errorLoggerMiddleware, returnErrorMiddleware }

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

 const { errorLoggerMiddleware, returnErrorMiddleware } = require('./errorMiddleware') app.use(errorLoggerMiddleware) app.use(returnErrorMiddleware)

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

6. أعد تشغيل التطبيق لمعالجة أخطاء المبرمج (Node.js)

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

7. التقاط جميع الاستثناءات التي لم يتم التعرف عليها (Node.js)

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

إليك كيف يمكنك القيام بذلك:

 process.on('uncaughtException', error => { console.log("ERROR: " + String(error)) // other handling mechanisms })

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

8. قبض على جميع حالات رفض الوعود التي لم تتم معالجتها (Node.js)

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

لذلك ، قد يفلت الوعد المهم الذي تم رفضه كتحذير ويترك تطبيقك مفتوحًا لإمكانية الوقوع في سلوك غير متوقع. لذلك ، من الضروري تنفيذ آلية احتياطية للتعامل مع رفض الوعد.

إليك كيف يمكنك القيام بذلك:

 const promiseRejectionCallback = error => { console.log("PROMISE REJECTED: " + String(error)) } process.on('unhandledRejection', callback)

ملخص

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

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

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

هل هناك أي أخطاء JavaScript أخرى لا يزال يتعذر عليك حلها؟ أي تقنيات للتعامل مع أخطاء JS بشكل بناء؟ اسمحوا لنا أن نعرف في التعليقات أدناه!