سؤال

في معظم الأوقات سأستخدم استثناءً للتحقق من شرط في الكود الخاص بي ، أتساءل عندما يكون الوقت المناسب لاستخدام تأكيد؟

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

Group group=null;
try{
    group = service().getGroup("abc");
}catch(Exception e){
    //I dont log error because I know whenever error occur mean group not found
}

if(group !=null)
{
    //do something
}

هل يمكن أن تشير إلى كيف أن التأكيد يناسب هنا؟ هل يجب أن أستخدم تأكيدًا؟

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

هل كانت مفيدة؟

المحلول

يجب استخدام التأكيدات للتحقق من شيء يجب ألا يحدث أبدًا ، في حين يجب استخدام استثناء للتحقق من شيء قد يحدث.

على سبيل المثال ، قد تقسم الوظيفة على 0 ، لذلك يجب استخدام استثناء ، ولكن يمكن استخدام تأكيد للتحقق من أن الصلبة تختفي فجأة.

من شأن التأكيد أن يمنع البرنامج من التشغيل ، لكن استثناء سيسمح للبرنامج بواصل الجري.

لاحظ أن if(group != null) ليس تأكيدا ، وهذا مجرد مشروط.

نصائح أخرى

من ذهني (قد تكون القائمة غير مكتملة ، وهي طويلة جدًا لتناسب تعليق) ، أود أن أقول:

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

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

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

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

كما يجب عليك قراءة مقالة أوراكل حول التأكيد لرؤية المزيد من الحالات التي يجب استخدامها - أو لا لاستخدامها - تأكيد.

كقاعدة عامة:

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

الرمز التالي من سؤالك هو نمط سيء و يحتمل أن يكون عربات التي تجرها الدواب

try {
    group = service().getGroup("abc");
} catch (Exception e) {
    //i dont log error because i know whenever error occur mean group not found
}

المشكلة هي أنك لا تعرف أن الاستثناء يعني أنه لم يتم العثور على المجموعة. من الممكن أيضًا أن service() ألقى استثناء استثناء ، أو أنه عاد null الذي تسبب بعد ذلك NullPointerException.

عندما تلتقط استثناء "متوقع" ، يجب عليك التقاط فقط استثناء أنك تتوقع. عن طريق اصطياد java.lang.Exception (وخاصة من خلال عدم تسجيله) ، فإنك تجعل من الصعب تشخيص / تصحيح المشكلة ، وربما السماح للتطبيق بإحداث المزيد من الضرر.

وفقا لهذا المستند http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#design-faq-general, "بيان التأكيد مناسب للشرط المسبق غير العام ، والتحقق من الشروط والفئة الثابتة. يجب أن يتم إجراء التحقق المسبق العام عن طريق الشيكات داخل الأساليب التي تؤدي إلى استثناءات موثقة على وجه الخصوص ، مثل غير شرعي غير شرعي."

إذا كنت ترغب في معرفة المزيد عن الشرط المسبق ، وشرط ما بعد ذلك ، فاصل الفصل ، تحقق من هذا المستند: http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#usage-conditions. كما أنه يحتوي على أمثلة على استخدام التأكيدات.

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

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

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

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

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

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

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

لذا باستخدام التأكيدات في جافا

  1. هي وسيلة أكثر إيجازا لكتابة حالة/مجموعة رمي
  2. يسمح لك بتشغيل هذه الشيكات/إيقافها عبر معلمات JVM. عادةً ما أترك هذه الشيكات طوال الوقت ، ما لم تؤثر على أداء وقت التشغيل أو لديك عقوبة مماثلة.

انظر القسم 6.1.2 (التأكيدات مقابل رمز الخطأ الآخر) من وثائق Sun في الرابط التالي.

http://www.oracle.com/technetwork/articles/javase/javapch06.pdf

يقدم هذا المستند أفضل نصيحة رأيتها عند استخدام التأكيدات. نقلاً عن المستند:

"هناك قاعدة جيدة تتمثل في أنه يجب عليك استخدام تأكيد لحالات استثنائية ترغب في نسيان التعامل مع."

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top