الصفحة الرئيسية>المتعلقة بالبرمجة>جافا كود المصدر
تنزيل

دليل أخطاء جافا سكريبت

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

يمكن العثور على حالات الاختبار للمحتوى الموجود في هذا الدليل على https://mknichel.github.io/javascript-errors/.

جدول المحتويات

  • مقدمة

  • تشريح خطأ جافا سكريبت

    • إنتاج خطأ جافا سكريبت

    • رسائل الخطأ

    • تنسيق تتبع المكدس

  • اكتشاف أخطاء جافا سكريبت

    • window.onerror

    • حاول/قبض

    • نقاط الدخول المحمية

    • وعود

    • عمال الويب

    • ملحقات كروم

مقدمة

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

تشريح خطأ جافا سكريبت

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

إنتاج خطأ جافا سكريبت

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

على سبيل المثال:

 فار أ = 3;أ();

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

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

 إذا (! تحقق الشرط المسبق ()) {
  رمي خطأ جديد ("لا يستوفي الشرط المسبق!")؛}

في هذه الحالة، سيكون الخطأ هو Error: Doesn't meet precondition! . سيحتوي هذا الخطأ أيضًا على تتبع مكدس يشير إلى السطر المناسب. يمكن معالجة الأخطاء التي يلقيها المتصفح ورمز التطبيق بنفس الطريقة.

هناك عدة طرق يمكن للمطورين من خلالها إلقاء خطأ في JavaScript:

  • throw new Error('Problem description.')

  • throw Error('Problem description.') <-- يعادل الأول

  • throw 'Problem description.' <-- سيء

  • throw null <-- والأسوأ من ذلك

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

رسائل الخطأ

يحتوي كل متصفح على مجموعته الخاصة من الرسائل التي يستخدمها للاستثناءات المضمنة، مثل المثال أعلاه لمحاولة استدعاء وظيفة غير وظيفية. ستحاول المتصفحات استخدام نفس الرسائل، ولكن نظرًا لعدم وجود مواصفات، فهذا غير مضمون. على سبيل المثال، {0} is not a function للمثال أعلاه بينما سيبلغ IE11 عن Function expected (وخاصة أيضًا بدون الإبلاغ عن المتغير الذي تمت محاولة استدعائه).

ومع ذلك، تميل المتصفحات إلى الاختلاف في كثير من الأحيان أيضًا. عندما تكون هناك عدة عبارات افتراضية في عبارة switch ، سيطرح Chrome "More than one default clause in switch statement" بينما سيُبلغ Firefox عن "more than one switch default" . ومع إضافة ميزات جديدة إلى الويب، يجب تحديث رسائل الخطأ هذه. يمكن تفعيل هذه الاختلافات لاحقًا عندما تحاول معالجة الأخطاء المبلغ عنها من التعليمات البرمجية المبهمة.

يمكنك العثور على النماذج التي تستخدمها المتصفحات لرسائل الخطأ على:

  • فايرفوكس - http://mxr.mozilla.org/mozilla1.9.1/source/js/src/js.msg

  • كروم - https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/messages.js

  • إنترنت إكسبلورر - https://github.com/Microsoft/ChakraCore/blob/4e4d4f00f11b2ded23d1885e85fc26fcc96555da/lib/Parser/rterrors.h

ستنتج المتصفحات رسائل خطأ مختلفة لبعض الاستثناءات.

تنسيق تتبع المكدس

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

يبدو تتبع المكدس الأساسي في Chrome كما يلي: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

يتكون كل إطار مكدس من اسم الوظيفة (إذا كان ذلك ممكنًا ولم يتم تنفيذ التعليمات البرمجية في النطاق العام)، والبرنامج النصي الذي جاء منه، ورقم السطر والعمود من التعليمات البرمجية.

لسوء الحظ، لا يوجد معيار لتنسيق تتبع المكدس، لذلك يختلف هذا باختلاف المتصفح.

يبدو تتبع المكدس الخاص بـ Microsoft Edge وIE 11 مشابهًا لمتصفح Chrome باستثناء أنه يسرد التعليمات البرمجية العامة بشكل صريح: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:3)
  at Global code (http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3)

يبدو تتبع مكدس Firefox كما يلي: 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9
  @http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

يشبه تنسيق Safari تنسيق Firefox ولكنه مختلف قليلاً أيضًا: 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:18
  global code@http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:13

نفس المعلومات الأساسية موجودة، لكن الشكل مختلف.

لاحظ أيضًا أنه في مثال Safari، وبصرف النظر عن اختلاف التنسيق عن Chrome، فإن أرقام الأعمدة تختلف عن كل من Chrome وFirefox. يمكن أيضًا أن تنحرف أرقام الأعمدة أكثر في حالات الخطأ المختلفة - على سبيل المثال في الكود (function namedFunction() { throwError(); })(); ، سيقوم Chrome بالإبلاغ عن العمود لاستدعاء الدالة throwError() بينما يقوم IE11 بالإبلاغ عن رقم العمود كبداية للسلسلة. ستعود هذه الاختلافات إلى العمل لاحقًا عندما يحتاج الخادم إلى تحليل تتبع المكدس بحثًا عن الأخطاء التي تم الإبلاغ عنها وإزالة تشويش تتبعات المكدس المبهمة.

راجع https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/Stack لمزيد من المعلومات حول خاصية مكدس الأخطاء. عند الوصول إلى خاصية Error.stack، يقوم Chrome بتضمين رسالة الخطأ كجزء من المكدس ولكن Safari 10+ لا يفعل ذلك.

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

وبالتعمق أكثر، هناك الكثير من الفروق الدقيقة لتكديس تنسيقات التتبع التي تمت مناقشتها في الأقسام أدناه.

تسمية الوظائف المجهولة

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

 setTimeout(function nameOfTheAnonymousFunction() { ... }, 0);

سيؤدي هذا إلى انتقال تتبع المكدس من: 

at http://mknichel.github.io/javascript-errors/javascript-errors.js:125:17

ل 

at nameOfTheAnonymousFunction (http://mknichel.github.io/javascript-errors/javascript-errors.js:121:31)

في Safari، سينتقل هذا من: 

https://mknichel.github.io/javascript-errors/javascript-errors.js:175:27

ل 

nameOfTheAnonymousFunction@https://mknichel.github.io/javascript-errors/javascript-errors.js:171:41

تضمن هذه الطريقة ظهور nameOfTheAnonymousFunction في الإطار لأي كود من داخل تلك الوظيفة، مما يجعل تصحيح الأخطاء أسهل بكثير. راجع http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/#toc-debugging-tips لمزيد من المعلومات.

إسناد وظائف إلى متغير

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

 var fnVariableName = function() { ... };

ستستخدم المستعرضات fnVariableName كاسم للوظيفة في تتبعات المكدس. 

    at throwError (http://mknichel.github.io/javascript-errors/javascript-errors.js:27:9)
    at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

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

 الدالة throwErrorFromInnerFunctionAssignedToVariable() {
  var fnVariableName = function() { throw new Error("foo"); };
  fnVariableName();}

سوف تنتج في فايرفوكس: 

throwErrorFromInnerFunctionAssignedToVariable/fnVariableName@http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37

في المتصفحات الأخرى، سيبدو هذا كما يلي: 

at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

يستخدم Firefox نص إطار مكدس مختلف للوظائف المحددة ضمن وظيفة أخرى.

خاصية اسم العرض

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

 var someFunction = function() {};someFunction.displayName = " # وصف أطول للوظيفة.";

لا توجد مواصفات رسمية لخاصية DisplayName، ولكنها مدعومة من قبل جميع المتصفحات الرئيسية. راجع https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/displayName وhttp://www.alertdebugging.com/2009/04/29/building-a-better -javascript-profiler-with-webkit/ لمزيد من المعلومات حول اسم العرض.

لا يدعم IE11 خاصية اسم العرض.

يستخدم Safari خاصية اسم العرض كاسم الرمز في تتبعات مكدس الأخطاء.

التقاط آثار المكدس برمجياً

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

في Chrome، من السهل جدًا القيام بذلك عن طريق استخدام Error.captureStackTrace API. راجع https://github.com/v8/v8/wiki/Stack%20Trace%20API لمزيد من المعلومات حول استخدام واجهة برمجة التطبيقات هذه.

على سبيل المثال:

 وظيفة تجاهلThisFunctionInStackTrace() {
  var err = new Error();
  Error.captureStackTrace(err,ignoreThisFunctionInStackTrace);
  إرجاع خطأ.المكدس؛}

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

 var err = new Error('');return err.stack;

ومع ذلك، يقوم IE10 بملء تتبع المكدس فقط عندما يتم طرح الخطأ فعليًا:

 يحاول {
  رمي خطأ جديد ('')؛} قبض (ه) {
  إرجاع e.stack;}

إذا لم تنجح أي من هذه الأساليب، فمن الممكن إنشاء تتبع مكدس تقريبي بدون أرقام الأسطر أو الأعمدة عن طريق التكرار على arguments.callee.caller callee.caller - لن يعمل هذا في الوضع الصارم ES5 على الرغم من أنه ليس أسلوبًا موصى به.

آثار المكدس غير المتزامنة

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

يدعم Chrome DevTools تتبعات المكدس غير المتزامن، أو بمعنى آخر التأكد من أن تتبع المكدس للخطأ يعرض أيضًا الإطارات التي حدثت قبل تقديم نقطة المزامنة. باستخدام setTimeout، سيؤدي هذا إلى تحديد من قام باستدعاء وظيفة setTimeout التي أنتجت خطأً في النهاية. راجع http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/ لمزيد من المعلومات.

سيبدو تتبع المكدس غير المتزامن كما يلي: 

  throwError	@	throw-error.js:2
  setTimeout (async)		
  throwErrorAsync	@	throw-error.js:10
  (anonymous function)	@	throw-error-basic.html:14

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

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

فقط Chrome DevTools يدعم أصلاً تتبعات المكدس غير المتزامنة.

تسمية البرامج النصية المضمنة والتقييم

ستستخدم تتبعات المكدس للتعليمات البرمجية التي تم تقييمها أو تضمينها في صفحة HTML عنوان URL الخاص بالصفحة وأرقام الأسطر/الأعمدة للتعليمات البرمجية التي تم تنفيذها.

على سبيل المثال: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

إذا كانت هذه البرامج النصية تأتي بالفعل من برنامج نصي تم تضمينه لأسباب تتعلق بالتحسين، فسيكون عنوان URL والأسطر وأرقام الأعمدة خاطئة. للتغلب على هذه المشكلة، يدعم Chrome وFirefox التعليق التوضيحي //# sourceURL= (لا يدعم ذلك Safari وEdge وIE). سيتم استخدام عنوان URL المحدد في هذا التعليق التوضيحي كعنوان URL لجميع تتبعات المكدس، وسيتم حساب رقم السطر والعمود بالنسبة إلى بداية علامة