سؤال

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

throw new InvalidOperationException("I'm not configured correctly!");
throw new ArgumentNullException("You passed a null!");
throw new StupidUserException("You can't divide by 0!  What the hell were you THINKING???  DUMMY!!!!!");

ما لهجة هل تأخذ عند كتابة استثناء الرسائل ؟ عند الذهاب من خلال سجلات هل تجد أي نمط معين من رسالة يساعد في الواقع أكثر من الأخرى ؟

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

المحلول

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

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

وشيء واحد هو أن من المفيد، في حالة عدم وجود حقل معين على استثناء للحصول على المعلومات، والبيانات المخالف:

throw new IndexOutOfBoundsException("offset < 0: " + off);

نصائح أخرى

ومجرد أن يكون واقع الأمر. يشمل جميع المعلومات التي من المحتمل تحتاج إلى عند التصحيح، ولكن ليس أكثر من ذلك.

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

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

وأنا تجنب علامات التعجب في كافة السلاسل (UI واستثناء) مثل الطاعون، باستثناء (ocasionally) في بلدي وحدة الاختبارات.

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

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

وموجزة، معلومات زائدة عن الحاجة مفصلة وقليل (أي ArgumentNullException تشارك الواضح أن فارغة).

ولكن هنا أفضل ما قرأت لبعض الوقت، الجواب الأول إلى <لأ href = "https://stackoverflow.com/questions/140376/what-easter-eggs-have-you-placed-in-code "> هذا .

وأنا لن تستخدم التعجب يمثل أكثر من اللازم. أنها تعبر عن الكثير، والتفكير في حقيقة أن "لا القرص في محرك الأقراص!" يمكن قراءة بأنها "لا القرص في محرك الأقراص أنت مجنون المستخدم." ؛)

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

throw new MagicalException(getText("magical.exception.text"));

وأوصي أيضا التفاف استثناء الأساسي (إذا كان لديك واحدة) عند رميها. وهو يساعد بالفعل التصحيح.

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

أجد معظم رسائل مفيدة توفير:

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

و الأكثر أهمية:

  • يقولون المستخدم كيفية إصلاح هذه المشكلة.

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

Error 203 (Timeout) in commit.c line 42:
Unable to save salary data for user 'Linus' to database at '10.10.1.21'
after 1500ms.  Verify database address and login credentials.

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

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

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

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