Хотя это скорее проблема с письменным языком, чем кодирование, это то, что программисты должны делать в обстоятельствах, когда копия не предоставляется клиентом или кем-то еще. Любые примеры сообщений об ошибках, хорошие или плохие, могут быть полезными.
Я кратко искал и не мог найти нить обмана. Хорошо, давай. Спасибо, все.
Пример:
"Извините, файл не удалось открыть. Проверьте, что файл еще не открыт другой программой и повторите попытку".
Если есть дополнительные сведения, которые напугают пользователя, например номер ошибки, или что-то еще, что только разработчик поймет, не показывайте их. Напишите их в файл журнала или нажмите кнопку сведений, которую можно нажать, чтобы добраться до них.
Я предполагаю, что вы говорите о том, чтобы показывать сообщения об ошибках пользователям в ящиках сообщений или на экране.
Вы имеете в виду пользовательский или в файле журнала для сотрудников admin/dev?
Я думаю, что они важны, в общем:
Я думаю, что все это важно, но известность будет меняться в зависимости от аудитории (как указывает dmckee). Другой совет (в общем) - ответить 5 Вт (кто, что,... и т.д.)
Я работаю в компании по обеспечению безопасности программного обеспечения, поэтому мой ответ может существенно отличаться от некоторых из приведенных выше ответов.
Хорошее сообщение об ошибке пользователя:
Сбалансированный между общим и конкретным - вы хотите предоставить пользователю достаточно информации, чтобы они могли исправить свою ошибку и двигаться дальше, но имейте в виду, что злоумышленник может использовать эти же сообщения об ошибках для атаки вашего сайта. Хорошим примером этого является контроль входа, в котором возвращается сообщение об ошибке "неправильный пароль для пользователя joe" или "user joe не существует в этой системе", это сообщает злоумышленнику, что они находятся на пути обнаружения правильных пользователей. Который, когда у вас нет ни имени пользователя, ни пароля, половина битвы.
Сообщает пользователю, что пошло не так - снова это сбалансировано между общим и конкретным. Пользователь никогда не должен видеть сообщение об ошибке ODBC, но может быть полезно узнать, что ошибка была вашей ошибкой и что они должны попробовать снова через несколько минут. Сообщите пользователю, что они могут сделать, чтобы помочь - если у вас есть система ведения бэкэнд-сервера (которая должна вам) регистрировать все, что, по вашему мнению, будет полезна, а затем сгенерировать идентификатор, который вы можете предоставить пользователю, чтобы они могли звонить или отправлять по электронной почте вам и расскажите вам о точном воспроизведении. Вы также можете автоматизировать это, разоблачая форму отправки ошибок при возникновении ошибки.
Будьте последовательны - используйте таблицу поиска ошибок, чтобы убедиться, что все ваши ошибки одинаковы (для той же проблемы) и что они хорошо написаны. Опечатки, орфографические ошибки и грамматические ошибки не могут быть допущены в производственном программном обеспечении.
Для конечных пользователей: сообщите пользователю, что делать. Если пользователь меняет какое-то входное значение, повторите попытку через 5 минут или позвоните по телефону?
Очевидно, что предотвращение ошибок лучше. Всегда предоставляйте пользователю достаточные сигналы для успешного выполнения задач (т.е. Объяснять требуемое форматирование полей ввода данных). Тем не менее, "Чтобы ошибаться человек..." и (применяя принципы удобства использования к ошибкам в веб-приложении), прощение является целью.
Для сообщений об ошибках существуют три основные функции:
1. Обратите внимание - во-первых, чтобы обеспечить эффективность, пользователь должен увидеть его
2. Опишите ошибку - сообщите пользователю о том, что пошло не так.
3. Предложить восстановление - дать полезные рекомендации по исправлению ошибки и продолжить
Все, что было сказано, я хотел бы скомпилировать что-то более подробно и особенно с примерами хороших и плохих сообщений об ошибках.
Хорошее сообщение об ошибке состоит из трех частей:
Если вы пишете или просматриваете сообщение об ошибке, сначала сосредоточьтесь на том, чтобы эти три очка были написаны. Даже если сообщение ужасно длинное, не волнуйтесь об этом при первой записи. Вы всегда можете вернуться назад и упростить его позже.
Но противоположное неверно. Его сложно сформировать небольшое сообщение в одно, которое четко объясняет проблему, причину и решение проблемы. Вы будете постоянно редактировать свои мысли, чтобы сообщение оставалось маленьким, и в какой-то момент вы будете заблокированы. Да, я несколько раз сталкивался с этой проблемой, поэтому я знаю, как это сложно.
После того, как вы убедитесь, что ваше сообщение содержит все эти три части, пришло время его просмотреть. Вы должны отредактировать его, чтобы убедиться в этом:
Как вы можете видеть, эта структура проста и не нуждается в большой мысли.
Источники:
К тому, что уже было сказано, я бы добавил:
Чтобы писать хорошие сообщения об ошибках, вам нужно подумать о каждой аудитории. Когда вы понимаете аудиторию, гораздо проще создавать сообщения об ошибках.
Во-первых, требования к сообщениям конечного пользователя:
Далее, требования к сообщениям техников поддержки:
Наконец, требования к сообщениям разработчиков поддержки:
Примером сообщения об ошибке, которое очень плохо для конечного пользователя, но которое может быть разумным для разработчика, является "Латентный кеш столкнулся с исходящими заголовками".: -)
Сообщения об ошибках должны:
С точки технической поддержки голоса важно также, чтобы сообщения об ошибках были уникальными. Если пользователь может сгенерировать одну и ту же ошибку "файл не может быть открыт" по-разному, это затрудняет людям технической поддержки точное определение того, что делает пользователь. Таким образом, сообщения об ошибках должны быть уникальными для каждого различного типа ошибок и, если возможно, предоставлять код ошибки или номер, чтобы пользователи знали, где искать проблему.
Мы обнаружили, что когда сообщения об ошибках содержат код ошибки, это помогает при технической поддержке. Когда пользователи сообщают сообщения об ошибках для поддержки людей, они часто смешивают или неправильно сообщают словесные сообщения об ошибках. Но если сообщение содержит номер ошибки, они очень хорошо сообщают о точной ошибке, например "Я получил ошибку 8512 при попытке распечатать отчет".
По возможности, это также помогает вести журнал ошибок. Много раз пользователи сообщают об ошибках при попытке выполнить определенную операцию, но они не будут точно помнить, что такое ошибка. Если есть журнал ошибок, с которыми можно связаться со стороны технической поддержки, это значительно облегчает определение проблемы.
Обычно стоит указать на общую причину проблемы, так как это поможет пользователю в 99,9% случаев ошибок.
Например, у нас есть два направления для инициализации. Один улавливает конфигурационные исключения, в которых говорится:
"Произошло распознанное исключение. Это может быть проблемой с конфигурацией"
а другой - неожиданно:
"Произошла непредвиденная ошибка."
Затем, в зависимости от настройки (включить или выключить dev), мы либо выводим информацию об dev, либо более подробную информацию о нем.
Сообщения об ошибках предназначены для конечных пользователей, а также для тех, кто должен поддерживать код
Сначала для конечных пользователей скажите им, что делать. Это может просто нажать Enter, чтобы продолжить, повторить попытку, закрыть и перезагрузить компьютер, чтобы перезагрузить компьютер.
Второй для сопровождающих, укажите как можно больше информации об ошибке. Слишком много. Я лично предпочитаю файл журнала для этого вместо сообщения об ошибке. Еще лучше указать, как конечный пользователь может отправить вам содержимое журнала из приложения.
Если вы можете сказать пользователю, что делать, попробуйте сделать это программно. По-моему, сообщения об ошибках должны появляться только в том случае, если программа сомневается в том, что делать. Подумайте, почему вы решили просто потерпеть неудачу: возможно, не беря на себя ответственность, чтобы попытаться восстановиться? Может быть, пользователь может сделать это намного проще? Может быть, пользователь должен решить, какое решение взять? Может быть, вы думали, что этого никогда не должно произойти (не забудьте сказать, что пользователь должен связаться с поддержкой или программистом в этом случае)?
Одна вещь, которая может повредить мою нервную систему, - это когда в сообщении об ошибке используется слово OR. "Файл не найден или нет разрешения или диска полностью, или ваша собака имеет плохую головную боль ИЛИ..." Пользователь действительно должен знать, какая из возможных причин ошибки произошла. Программисты избегают ошибок в сообщениях об ошибках.
Не копируйте сообщения об ошибках в разные места кода. Если пользователь видит сообщение в вашей программе и отправляет обратную связь, более удачным случаем является то, когда вы можете понять, что означало ваше сообщение об ошибке. Менее удачным случаем является то, что вы по крайней мере можете grep весь исходный код и найти место, где программа разбилась. Если вы найдете одно и то же сообщение в нескольких местах, вы не можете помочь себе.
О, и не забудьте упомянуть о возможных последствиях: "Система предотвращения белков перестает работать. Все, что хранится на ваших жестких дисках, может быть случайно изменено белками". "Система профилактики белков перестает работать. Белки будут предотвращены только с помощью общей профилактики". Существует различие в степени тяжести.
Помните, прежде всего, что конечный пользователь не заботится о технологическом nitty-gritty. Только он работает. Когда это не работает, он или она заботится только о том, как он влияет на то, что они пытаются сделать. Полезное сообщение об ошибке должно быть сосредоточено на what, а не на why.
Здесь может быть несколько различных контекстов (хотя я уверен, что это упоминалось снова и снова):
1) Если мы говорим о том, что веб-сайт должен дать сообщение "Oops, something badused", тогда должен быть простой язык, чтобы сообщить пользователю, что произошла ошибка, повторите попытку, и если есть еще проблемы с контактная поддержка в бла-бла-бла...
2) Если мы говорим о регистрации исключений, созданных в коде для администраторов и разработчиков sys для чтения, тогда вопрос становится более важным для того, чтобы исключить сообщение об исключении и трассировку стека в файл журнала, электронную почту, или средство просмотра событий, чтобы его можно было обрабатывать по-разному в зависимости от того, насколько срочным является то, что кто-то смотрит на это.
3) Если мы говорим о написании сообщения для исключения, то мое предложение состоит в том, чтобы четко указать, какое условие ошибки было выполнено, например. есть ли нулевая ссылка, где не должно быть или есть что-то хуже, чем файл, который должен существовать, отсутствует вместе с серьезностью ошибки, например. может ли приложение продолжать работать или выйти на страницу с ошибкой в этом состоянии.
От перспектив пользователей.