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

Question

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

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

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

ОШИБКА КОМПИЛЯЦИИ ПРИЧИНА 3

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

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

Answer 1

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

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

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

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

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

Ориентируйтесь на правильную аудиторию.

Answer 2

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

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

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

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

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

В самый раз:

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

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

Answer 3

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

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

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

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

Наконец, предоставьте несколько простых и понятных команд для пользователя ("Повторите попытку", "Отмена" и т.д.).

Answer 4

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

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

Answer 5

Настолько подробные, насколько это необходимо ;)

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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