Какой стиль Вы используете для сообщений об исключениях? [закрытый]

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

Но здесь является лучшим, я читал некоторое время, сначала ответьте на это.

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

Я избегаю восклицательных знаков во всех строках (UI и исключение) как эпидемия, кроме (иногда) в моих модульных тестах.

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

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

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

Вещи вроде "Я не могу найти файл, который Вы хотели, Вы проверите, чтобы видеть, что у меня есть он правильно?" или "Что-то пошло не так, как надо. Не знайте то, что, но единственный способ, которым я могу быть зафиксирован, путем остановки. Перезапустите меня".

Я не использовал бы восклицательные знаки слишком много. Они выражают слишком много, думайте о том, что "Никакой диск в диске!" может быть считан как "Никакой диск в диске Вы сумасшедший пользователь".;)

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

throw new MagicalException(getText("magical.exception.text"));

Я также рекомендую перенести базовое исключение (если у Вас есть один) при броске его. Это действительно помогает отладке.

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

Я склонен работать свои сообщения об исключениях в исключение сами. Например, file_not_found должен сказать "файл, не найденный". Определенные данные должны только быть включены, если пользователь не может понять это; в этом случае пользователь знает имя файла, таким образом, я не добавляю те данные. Форматирование может быть сделано любыми выводами информация при необходимости, таким образом, я пытаюсь сделать их максимально дружелюбными по отношению к переформатированию.

Вежливый, краткий, простой, конкретный. Часто, включая значения состояния в сообщении полезно.

Я нахожу, что самые полезные сообщения обеспечивают:

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

И самый важный:

• Они говорят пользователю, как решить проблему.

Пример:

Error 203 (Timeout) in commit.c line 42:
Unable to save salary data for user 'Linus' to database at '10.10.1.21'
after 1500ms.  Verify database address and login credentials.

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