Насколько подробны сообщения об ошибках?

Question

Мне было интересно, каков общий консенсус в отношении сообщений об ошибках. Насколько они должны быть подробными?

Я работал над проектами, в которых появилось другое сообщение об ошибке для ввода числа, которое было слишком большим, слишком маленьким, имело десятичное значение, было строкой и т. Д. Это было очень приятно для пользователя, поскольку они точно знали где все пошло не так, но код обработки ошибок начал конкурировать с фактической бизнес-логикой в ​​размере и начал разрабатывать некоторые из своих ошибок.

С другой стороны, я работал над проектом, где вы получите очень общие ошибки, такие как

COMPILE НЕ ПРИЧИНА 3

Что Излишне говорить было почти полностью бесполезным, так как причина 3 оказалась ошибкой связи.

Итак, где же находится средняя точка? Как узнать, добавили ли я достаточно описательные сообщения об ошибках? Как узнать, сможет ли пользователь понять, где они поступили неправильно?

Answer 1

Существует две возможные целевые аудитории для сообщения об ошибке, пользователя и разработчика.

Как правило, сообщение должно указывать на пользователя.

o что является причиной проблемы.
o Почему программа не может решить проблему
o что пользователь может сделать для решения этой проблемы.
o как сообщить о проблеме.

Если проблема должна быть представлена, отчет должен включать как можно больше информации о контексте программы.

имя о модуле
о имя_функции
о номере строка
о переменных интересе в общей области проблем
о, может быть, даже дамп ядра.

Целевая аудитория.

Answer 2

Вы должны сообщить, что произошло, и какие параметры пользователя, в максимально возможном количестве слов. Чем длиннее сообщение об ошибке, тем менее вероятно, что пользователь должен его прочитать. Точно так же короткие сообщения об ошибках являются загадочными и бесполезными. Там есть сладкое пятно с точки зрения длины, и оно отличается для каждой ситуации.

Слишком короткое:

Неверный ввод.

Слишком долго:

Пожалуйста, введите правильный формат IP-адрес, например, 192.168.0.1. IP-адрес - это номер, используемый для идентификации вашего компьютера в сети.

Просто право:

Пожалуйста, введите действительный IP-адрес.

Что касается раздувания кода, если небольшой дополнительный код не позволит пользователю звонить или получать выгоду, то это хорошая инвестиция.

Answer 3

Я бы ошибался на стороне более подробно, но, думаю, вы ответили на свой вопрос. Чтобы избежать раздувания кода, укажите полезную информацию в сообщении о кодах/ошибках, но вы можете предоставить более подробную информацию в документации, возможно, или с помощью файлов справки или часто задаваемых вопросов.

Слишком мало информации хуже, на мой взгляд.

Если вы используете язык с богатой интроспекцией или другими возможностями, журнал с его строкой, которая не прошла проверку, была бы полезна. Затем пользователь может перейти к технической поддержке или получить подробную информацию, и это не дополнительный раздутый код, а использование вашего собственного кода для предоставления информации.

Answer 4

Существует два типа сообщений об ошибках: те, которые будут отображаться пользователем, и те, которые будут видны программисту.

«Как узнать, сможет ли пользователь понять, где они поступили неправильно?» Я предполагаю, что эти сообщения будут отображаться только пользователем, а не очень технические, а COMPILE FAILED REASON 3 не является типичным сообщением об ошибке конечного пользователя. Это то, что видит программист (пользователь обычно не компилирует вещи).

Так что, если это пользователь, который будет видеть:

1. Обеспечить короткий «Это сообщение об ошибке» («Ops Что-то пошло не так!», И т.д.)
2. Обеспечить небольшое общее описание ошибки («Сайт, к которому вы пытаетесь подключиться, кажется, недоступен»/«У вас нет достаточных разрешений для выполнения задачи XYZ»/etc.)
3. Добавить «Детали >> ", если ваш пользователь хорошо разбирается в компьютерах, включая подробную информацию (трассировка стека исключений, код ошибки и т. д.)

Наконец, обеспечивают некоторые простые и понятные команды для пользователя («Попробуйте еще раз», «Отмена» и т.д.)

Answer 5

Реальный вопрос о сообщениях об ошибках, если они даже должны отображаться. Множество сообщений об ошибках предоставляется пользователю, но для их исправления нет НИКАКИХ способов.

До тех пор, пока есть возможность исправить ошибку, дайте пользователю достаточно информации, которая позволит им исправить ее самостоятельно. Если они не могут самостоятельно исправить это, есть ли причина сказать им техническую причину аварии? Нет, просто зарегистрируйте его в файле для устранения неполадок позже.

Answer 6

Как подробно описано, как они должны быть;)

Я знаю, что это звучит как умный задницу ответ, но так это зависит от вашей целевой аудитории и типа ошибки. Для ошибок, вызванных недействительной записью пользователя, вы можете показать им, что представляет собой действительную запись. Для ошибок, которые пользователь не может контролировать, может возникнуть общее сообщение типа «мы работаем над этим».

Я согласен с комментариями Джона Б. относительно длины.

Answer 7

Сообщения об ошибках должны быть детализированными, но ясными. Это может быть достигнуто путем объединения сообщений об ошибках с нескольких уровней:

Failed to save the image 
Permission denied: /foo.jpg 

Здесь у нас есть два уровня. Их может быть больше. Сначала мы расскажем общую картину, а затем расскажем подробности. Порядок таков, что сначала мы понимаем часть, которую понимают большинство, а затем часть, которую люди не понимают, но все еще могут быть видны.

Дополнительно может быть предложение исправить.