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

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

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

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

ПРИЧИНА НЕУДАЧИ КОМПИЛЯЦИИ 3

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

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


error-handling user-interface custom-errors
person ReaperUnreal    schedule 31.12.2008    source источник

Ответы (7)


arrow_upward
12
arrow_downward

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

Обычно сообщение должно быть нацелено на пользователя.

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

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

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

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

person EvilTeach    schedule 31.12.2008
comment
как сообщить о проблеме - или, что лучше, уверенность в том, что о проблеме уже сообщили - person Chris Noe; 31.12.2008
comment
+1 по этому поводу. Вы не хотите предоставлять ненужные нажатия. Я не могу представить себе многих пользователей, которых это расстроило бы. - person Jonta; 23.01.2009

arrow_upward
4
arrow_downward

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

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

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

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

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

В самый раз:

Пожалуйста, введите действующий IP-адрес.

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

person Jon B    schedule 31.12.2008
comment
В самый раз могло быть и меньше. Я бы ожидал информации о том, что ввел пользователь, И пример того, что он должен ввести. Что-то вроде «Не понимаю 192,168,02». Пожалуйста, введите действительный IP-адрес (например, 192.168.0.2). - person stefan bachert; 02.05.2012

arrow_upward
3
arrow_downward

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

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

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

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

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

person luiscubal    schedule 31.12.2008
comment
Продукт для загадочного сообщения об ошибке был компилятором, так что в этом случае да, они будут компилировать вещи. Но точка зрения принята правильно. - person ReaperUnreal; 31.12.2008

arrow_upward
2
arrow_downward

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

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

person Adam Peck    schedule 31.12.2008
comment
Я ненавижу, когда программы падают, и мне нужно найти файл журнала для сообщения об ошибке в Google. Даже если это не обязательно исправить, предоставив мне кое-что, что я могу, Google может позволить мне обойти это намного проще. - person Andrew Coleson; 31.12.2008
comment
Если это не поправимо, то как Google вам поможет? Если есть способ исправить проблему, Google поможет, но не обязательно, если вы объясните, как правильно исправить это в первую очередь. - person Adam Peck; 31.12.2008

arrow_upward
2
arrow_downward

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

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

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

person AlexCuse    schedule 31.12.2008

arrow_upward
1
arrow_downward

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

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

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

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

person iny    schedule 31.12.2008

arrow_upward
0
arrow_downward

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

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

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

person Tim    schedule 31.12.2008