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

Question

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

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

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

СООТВЕТСТВУЮЩАЯ НЕПРАВИЛЬНАЯ ПРИЧИНА 3

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

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

Answer 1

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

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

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

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

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

Выберите нужную аудиторию.

Answer 2

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

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

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

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

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

В самый раз:

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

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

Answer 3

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

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

Итак, если это увидит пользователь:

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

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

Answer 4

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

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

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

Answer 5

Реальный вопрос о сообщениях об ошибках заключается в том, должны ли они вообще отображаться. Пользователю предоставляется множество сообщений об ошибках, но НЕТ СПОСОБА их исправлять.

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

Answer 6

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

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

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

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

Answer 7

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

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

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