Как написать хорошие сообщения об ошибках?

Question

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

Я ненадолго искал и не смог найти двойную ветку. Хорошо, есть на это. Спасибо всем.

Answer 1

Обычно стоит указать общую причину проблемы, поскольку это поможет пользователю в 99,9% случаев ошибки.

Например, у нас есть два направления для проблем инициализации. Один ловит исключения конфигурации, которые заявляют:

"Признано исключение. Это может быть проблема с конфигурацией"

и еще один для неожиданного:

«Произошла непредвиденная ошибка.»

Затем, в зависимости от настройки (включение или выключение dev), мы либо выводим информацию dev, либо более удобную для пользователя информацию.

Answer 2

Сообщения об ошибках должны:

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

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

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

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

Answer 3

Здесь можно отметить несколько различных контекстов (хотя я уверен, что это упоминалось снова и снова):

1) Если мы говорим о веб-сайте, который должен дать сообщение «Упс, случилось что-то плохое», то должен быть простой язык, чтобы сообщить пользователю, что произошла ошибка, пожалуйста, попробуйте еще раз, и если по-прежнему есть обратитесь в службу поддержки в Blah Blah Blah ...

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

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

Answer 4

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

Answer 5

с точки зрения пользователей.