JavaScript Try/Catch: أخطاء أم استثناءات؟

Question

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

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

catch(err) {
DFTools.console.log("someMethod caught an error: ",err.message);
...

أو:

catch(ex) {
DFTools.console.log("someMethod caught an exception: ",ex.message);
...

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

Answer 1

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

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

Answer 2

ال مواصفات ecmascript يدعوهم استثناءات. قد ترغب في القيام بالمثل.

لجعل تسجيل الدخول الخاص بك أكثر إفادة:

catch(ex) {
    DFTools.console.log("someMethod caught an exception of type " 
       + ex.name + ": ", ex.message);

قد ترغب أيضًا في أن تضع في اعتبارك أن الاستثناءات (للأسف) يمكن أن تكون من أي نوع ، وبالتالي لا يوجد بالضرورة name و message ملكيات:

catch(ex) {
    if (ex.message && ex.name) {        
        DFTools.console.log("someMethod caught an exception of type " 
           + ex.name + ": ", ex.message);
    } else /* deal with it somehow */

نظرًا لأن هذا بدأ يبدو مرهقًا جدًا لتكراره في كل مكان ، فقد ترغب في التقاطها في وظيفة:

function logExceptions(methodName, action) {

    try {

        action();

    } catch (ex) {
        if (ex.message && ex.name) {        
            DFTools.console.log("someMethod caught an exception of type " 
               + ex.name + ": ", ex.message);
        } else {
            DFTools.console.log("someMethod caught a poorly-typed exception: " + ex);
        }
    }
}

الآن يمكنك أن تقول:

logExceptions(function() {

    // do some risky stuff...

});

Answer 3

في JavaScript يطلق عليه خطأ الصيد. لذلك أود أن أقترح عليك استخدام الخطأ بدلاً من الاستثناء. اترك الاختيار في الوسط باستخدام "E". كما في أمثلة موزيلا.مرجع Mozilla Core JavaScript 1.5

Answer 4

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

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

Answer 5

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

أنا أزعم أن "استثناء استثنائي". خطأ أقل غير متوقعة.

تنصل: الكود الزائف التالي ليس جيدًا ؛ إنه بمثابة الحد الأدنى للحالة التي يمكن أن أفكر فيها لتوضيح وجهة نظري.

ملاحظة: في تجربة الفكر هذه ، يعيد GetFile غير محدد إذا لم يتمكن من العثور على الملف المحدد.

function AlwaysGetFile(name){
    var file = null;
    if(FileExists(name)){
        file = GetFile(name);
        if(typeof file === "undefined"){
            throw new "couldn't retrieve file" EXCEPTION
        }
    }
    else{
        throw new "file does not exist" ERROR
    }
    return file;
}

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

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

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

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

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

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

Answer 6

ما تحصل عليه في كتلة الصيد هو استثناء ، لذلك أسمه كاستثناء ...

إذا كان خطأ - يمكنني التعامل معه في الكود الخاص بي وعادة ما لا أتوقع رؤيته في كتلة الصيد

HTH.