ما هي رسالة الخطأ المناسبة التي سيتم توفيرها إلى شروط Google Guava المسبقة.* الأساليب؟
-
30-09-2019 - |
سؤال
على سبيل المثال عند استخدام الشروط المسبقة, ، هل من المفترض أن تعكس رسالة الخطأ حالة النجاح أو الحالة الفاشلة للتحقق من السؤال؟
import static com.google.common.base.Preconditions.*;
void doStuff(int a, int b) {
checkArgument(a == b, "a == b");
// OR
checkArgument(a == b, "a != b");
}
المحلول
لفحص الشروط المسبقة ، قائلة المتطلبات في الاستثناء ، تكون رسالة التفاصيل أكثر إفادة من مجرد ذكر الحقائق. كما أنه يؤدي إلى الكثير من كود القراءة بشكل طبيعي:
ال توثيق يوفر المثال التالي:
هذا يسمح بإنشاءات مثل
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 ، تليها سلسلة تتناقض مع هذا التعبير.
الجانب السلبي الآخر لتوضيح الحقائق هو أنه بالنسبة للشروط المسبقة المعقدة ، من المحتمل أن يكون أقل إفادة ، لأن المستخدم قد يعرف بالفعل الحقيقة ، ولكن ليس ما هي المتطلبات الفعلية التي يتم انتهاكها.
أسئلة ذات صلة
نصائح أخرى
يعطي الوثائق أمثلة تجعلها واضحة جدًا باستخدام الكلمات بدلاً من الرموز:
checkArgument(count > 0, "must be positive: %s", count);
بالنظر إلى أن هذه ستكون رسائل استثناء في السجلات (أو جلسات تصحيح الأخطاء) ، فافعل كل ما تعتقد أنه سيوضح أي شخص ينظر إلى مشكلة ، أو أي شخص يقرأ الكود لفهم الشرط المسبق.
علي سبيل المثال انت استطاع أعد كتابة ما سبق على النحو التالي:
checkArgument(count > 0, "count must be positive; was actually %s", count);
شخصيا ، لشيء مثل هذا أعتقد أنني سأكتب
checkArgument(a == b, "a (%s) must equal b (%s)", a, b);
في كثير من الأحيان (معظم الوقت) يمكنك فقط استخدام طريقة checkargument () بدون معلمة رسالة الخطأ ، أي عدم توفير رسالة الخطأ على الإطلاق.
لإنشاء رسالة خطأ جيدة يحتاج المرء إلى فهم من سيقرأ الرسالة. إنه ليس المستخدم النهائي. إذا فشل الشرط المسبق ، فإنه يشير إلى وجود خطأ في الكود. قد يفسر النص الشرط المسبق الفاشل ، ولكن في معظم الحالات لا فائدة من المستخدم النهائي ، من المفترض أن يكون تلميحًا للمبرمج. في معظم الأوقات ، فإن الرسالة في حد ذاتها لا معنى لها أيضًا بدون رمز StackTrace ورمز المصدر. في الواقع ، في معظم الحالات ، فإن رمز StackTrace والرمز المصدر هو بالضبط ما يحتاجه المبرمج لإصلاح خطأ ، لا تساعد رسالة الخطأ. إذا لم يكن الشرط المسبق واضحًا ، فإن التعليق المجاور له هو وسيلة مثالية لتوثيقه.
إن الحاجة إلى توفير رسالة خطأ دائمًا في الحالات ، لا يهتم أحد حقًا بالنص إلى أن المبرمجين يجعلون رسائل عديمة الفائدة وواضحة وليست مفيدة تجعل الكود أقل قابلية للقراءة.
هناك بعض الحالات ، عندما يمكن أن تكون رسالة الخطأ مفيدة ، على سبيل المثال ، يمكن أن تحتوي الرسالة على القيم الفعلية للمتغيرات ، ولكن من تجربتنا التي لا تكون في كثير من الأحيان ، وفي هذه الحالات يمكنك استخدام الرسالة.
تنطبق حجج مماثلة أيضًا في أساليب التأكيد في Junit ؛ إن تقديم رسالة خطأ دائمًا ليس فكرة جيدة.
أيضًا ، عندما تستخدم شروط مسبقة في مكتبة بدلاً من تطبيق للمستخدمين النهائيين ، قد تكون الأمور مختلفة لأنك لا تعرف كيف سيتم استخدام الكود الخاص بك.
كما 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")
يعطيك هذا:
نفس المدخلات ، إخراج أفضل.
(إذا لم تدعم المحطة الخاصة بك الألوان ، فستحصل على اختلاف نصي بدلاً من ذلك)