ما هي رسالة الخطأ المناسبة التي سيتم توفيرها إلى شروط Google Guava المسبقة.* الأساليب؟

Question

على سبيل المثال عند استخدام الشروط المسبقة, ، هل من المفترض أن تعكس رسالة الخطأ حالة النجاح أو الحالة الفاشلة للتحقق من السؤال؟

import static com.google.common.base.Preconditions.*;

void doStuff(int a, int b) {
  checkArgument(a == b, "a == b");
  // OR
  checkArgument(a == b, "a != b");
}

Answer 1

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

ال توثيق يوفر المثال التالي:

هذا يسمح بإنشاءات مثل

 if (count <= 0) {
   throw new IllegalArgumentException("must be positive: " + count);
 }

ليتم استبدالها بأكثر إحكاما

 checkArgument(count > 0, "must be positive: %s", count);

شيئان ملحوظة:

• يوضح المثال بوضوح الشرط بدلاً من الحقيقة
  • "شيئا ما لا بد وأن حقا"، بدلاً من "شيئا ما هو خاطئ - ظلم - يظلم"
• عن طريق قلب حالة الشيك ، فإن البنية بأكملها تقرأ بشكل طبيعي

بعد هذا المثال ، ستكون رسالة أفضل هي:

checkArgument(a == b, "a must be equal to b"); // natural!

يمكنك حتى الذهاب خطوة إلى الأمام والتقاط قيم a و b في رسالة الاستثناء (انظر الإصدار 2nd الفعال Java ، البند 63: قم بتضمين معلومات التقاط الفشل بالتفصيل رسائل):

checkArgument(a == b, "a must be equal to b; instead %s != %s", a, b);

بديل ذكر الحقائق أقل طبيعية للقراءة في الكود:

checkArgument(a == b, "a != b");              // awkward!
checkArgument(a == b, "a is not equal to b"); // awkward!

لاحظ مدى حرج القراءة في تعبير Java Code One Boolean ، تليها سلسلة تتناقض مع هذا التعبير.

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

أسئلة ذات صلة

• رسالة خطأ فحص فارغة على أنها "خالية" أو "كان فارغًا"

Answer 2

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

checkArgument(count > 0, "must be positive: %s", count);

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

علي سبيل المثال انت استطاع أعد كتابة ما سبق على النحو التالي:

checkArgument(count > 0, "count must be positive; was actually %s", count);

Answer 3

شخصيا ، لشيء مثل هذا أعتقد أنني سأكتب

checkArgument(a == b, "a (%s) must equal b (%s)", a, b);

Answer 4

في كثير من الأحيان (معظم الوقت) يمكنك فقط استخدام طريقة checkargument () بدون معلمة رسالة الخطأ ، أي عدم توفير رسالة الخطأ على الإطلاق.

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

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

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

تنطبق حجج مماثلة أيضًا في أساليب التأكيد في Junit ؛ إن تقديم رسالة خطأ دائمًا ليس فكرة جيدة.

أيضًا ، عندما تستخدم شروط مسبقة في مكتبة بدلاً من تطبيق للمستخدمين النهائيين ، قد تكون الأمور مختلفة لأنك لا تعرف كيف سيتم استخدام الكود الخاص بك.

Answer 5

كما Polygenelubrecants أشار:

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

بينما يمكنك بالتأكيد القيام بذلك مع شروط الجوفية المسبقة ، متطلبات API (الذي قمت بتأليفه) يتيح لك تحقيق إخراج أفضل دون أي جهد من جانبك.

شروط الجوافة المسبقة

String a = "foosball";
String b = "ballroom";
Preconditions.checkArgument(a == b, "a == b");

يعطيك هذا:

java.lang.IllegalArgumentException: a == b
    at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
    at Main.main(Main.java:142)

متطلبات API

String a = "foosball";
String b = "ballroom";
requireThat(a, "a").isEqualTo(b, "b")

يعطيك هذا:

نفس المدخلات ، إخراج أفضل.

(إذا لم تدعم المحطة الخاصة بك الألوان ، فستحصل على اختلاف نصي بدلاً من ذلك)