ما مدى التفصيل الذي يجب أن تكون عليه رسائل الخطأ؟
https://stackoverflow.com/questions/403333
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
كنت أتساءل ما هو الإجماع العام على رسائل الخطأ.ما مدى التفصيل الذي ينبغي أن تكون عليه؟
لقد عملت في مشاريع ظهرت فيها رسالة خطأ مختلفة لإدخال رقم كبير جدًا، أو صغير جدًا، أو يحتوي على علامة عشرية، أو عبارة عن سلسلة، وما إلى ذلك.كان ذلك أمرًا رائعًا بالنسبة للمستخدم لأنه كان يعرف بالضبط أين سارت الأمور على نحو خاطئ، لكن كود معالجة الأخطاء بدأ ينافس منطق العمل الفعلي من حيث الحجم، وبدأ في تطوير بعض الأخطاء الخاصة به.
على الجانب الآخر، عملت في مشروع حيث قد تحصل على أخطاء عامة جدًا مثل
تجميع سبب الفشل 3
وغني عن القول أنه كان عديم الفائدة تمامًا تقريبًا حيث تبين أن السبب 3 يعني خطأ في الارتباط.
إذن أين الحل الوسط؟كيف أعرف إذا قمت بإضافة رسائل خطأ وصفية كافية؟كيف أعرف ما إذا كان المستخدم سيكون قادرًا على فهم الأخطاء التي ارتكبها؟
المحلول
وهناك نوعان من الممكن الجمهور المستهدف لرسالة الخطأ، المستخدم، والمطور.
واحد ينبغي أن يكون عموما الرسالة تستهدف المستخدم.
س ما هو سبب المشكلة.
س لماذا البرنامج لا يمكن أن تعمل على حل المشكلة
س ما يمكن للمستخدم القيام كمحاولة للتغلب على هذه المشكلة.
س كيف للإبلاغ عن المشكلة.
وإذا كانت المشكلة هي أن يتم الإبلاغ عنها، ينبغي أن يتضمن التقرير أكبر قدر من المعلومات سياق البرنامج ممكن.
س اسم الوحدة النمطية
س اسم الدالة
س رقم السطر
س متغيرات الفائدة في المنطقة العامة من مشكلة
س ربما تفريغ الأساسية.
واستهداف الجمهور الصحيح.
نصائح أخرى
ويجب أن التواصل ما حدث، وما هي الخيارات المتاحة للمستخدم، في عدد قليل ممكن من الكلمات. ويعد رسالة الخطأ، وأقل احتمالا المستخدم لقراءته. وعلى نفس المنوال، رسائل الخطأ قصيرة هي خفي وغير مجدية. هناك بقعة الحلو من حيث الطول، وانها مختلفة في كل حالة.
وقصيرة جدا:
<اقتباس فقرة>والمدخلات غير صالح.
وطويل جدا:
<اقتباس فقرة>يرجى إدخال عنوان IP مهيأ بشكل صحيح، مثل 192.168.0.1. عنوان IP هو رقم يستخدم لتعريف جهاز الكمبيوتر الخاص بك على الشبكة.
والحق فقط:
<اقتباس فقرة>يرجى إدخال عنوان IP صالح.
وبقدر ما يتعلق الأمر سخام الرمز، إذا رمز بقليل سوف يمنع المستخدم من استدعاء الدعم أو الحصول على frustraited، ثم انه استثمار جيد.
هناك نوعان من رسائل الخطأ:تلك التي سيراها المستخدم وتلك التي سيراها المبرمج.
"كيف أعرف ما إذا كان المستخدم سيتمكن من فهم أين أخطأوا؟" أفترض أن هذه الرسائل ستشاهدها المستخدم فقط ، وليست تقنية للغاية ، و COMPILE FAILED REASON 3 ليست رسالة خطأ نموذجية للمستخدم النهائي.إنه شيء سيراه المبرمج (لا يقوم المستخدم عادةً بتجميع الأشياء).
لذلك، إذا كان المستخدم هو الذي سيراه:
- قم بتقديم رسالة قصيرة "هذه رسالة خطأ"("Ops!حدث خطأ ما!"، الخ.)
- قم بتوفير وصف عام صغير للخطأ ("يبدو أن الموقع الذي تحاول الاتصال به غير متاح"/"يبدو أنه ليس لديك الأذونات الكافية لتنفيذ مهمة XYZ"/إلخ.)
- أضف زر "التفاصيل >>"، في حالة فهم المستخدم لأجهزة الكمبيوتر جيدًا، بما في ذلك المعلومات التفصيلية (تتبع مكدس الاستثناءات، ورمز الخطأ، وما إلى ذلك)
أخيرًا، قم بتوفير بعض الأوامر البسيطة والمفهومة للمستخدم ("حاول مرة أخرى"، "إلغاء"، وما إلى ذلك)
والسؤال الحقيقي حول رسائل الخطأ إذا كان ينبغي حتى يتم عرضها. وتعرض الكثير من رسائل الخطأ لمستخدم ولكن هناك NO WAY لهم لتصحيح هذه.
وطالما هناك طريقة لتصحيح الخطأ ثم إعطاء معلومات كافية للمستخدم من شأنها أن تسمح لهم لتصحيح ذلك من تلقاء نفسها. إذا لم تكن قادرا على تصحيح ذلك من تلقاء أنفسهم هل هناك أي سبب لنقول لهم سبب فني لتحطم؟ لا مجرد تسجيل إلى ملف لاستكشاف لاحقا.
وكما هو مفصل لأنها تحتاج إلى أن يكون؛)
وأنا أعلم أنه يبدو وكأنه الجواب الحمار الذكية ولكن الكثير من هذا يعتمد على جمهورك المستهدف ونوع من الخطأ. عن الأخطاء الناجمة عن دخول مستخدم غير صالح، هل يمكن أن تبين لهم ما يشكل دخول صالح. عن الأخطاء التي لا يمكن للمستخدم التحكم، وعامة "نحن نعمل على ذلك" نوع الرسالة قد تفعل.
وأنا أتفق مع تعليق جون باء بشأن طول كذلك.
ورسائل الخطأ، ولكن واضح. ويمكن تحقيق ذلك من خلال الجمع بين رسائل الخطأ من مستويات متعددة:
Failed to save the image
Permission denied: /foo.jpg
وهنا لدينا مستويين. يمكن أن يكون هناك أكثر من ذلك. أولا نقول الصورة الكبيرة ومن ثم نقول للتفاصيل. النظام هو من هذا القبيل أن علينا أولا أن الجزء يفهمها معظم ثم الجزء أقل الناس يفهمون، ولكن على حد سواء يمكن أن تكون مرئية.
وبالإضافة إلى ذلك يمكن أن يكون هناك اقتراح الإصلاح.
وأود أن يتجه الى جانب المزيد من التفاصيل، ولكن أعتقد أنك أجبت على السؤال الخاص بك. لتجنب نفخ في الكود ثم توفير المعلومات المفيدة في الرسالة / رمز خطأ ولكن يمكنك إعطاء مزيد من التفاصيل في وثائق ربما أو مع ملفات المساعدة أو التعليمات.
وجود معلومات قليلة جدا هو أسوأ في رأيي.
إذا كنت تستخدم لغة مع التأمل غنيا أو غير ذلك من القدرات، وسجل مع انه الخط الذي فشل فإن الاختيار سيكون مفيدا. يمكن للمستخدم ثم إلى الأمام إلى الدعم الفني أو الحصول على معلومات مفصلة وهذا ليس إضافي سخام الرمز، ولكن باستخدام التعليمات البرمجية الخاصة بك لتوفير المعلومات.
