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

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

Пример: «Я не могу найти нужный вам файл, не могли бы вы проверить, правильно ли он у меня?» или «Что-то пошло не так. Не знаю, что, но единственный способ исправить это - остановиться. Пожалуйста, перезапустите меня».

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

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

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

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

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

Но вот лучшее, что я читал за какое-то время, - первый ответ на это.

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

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

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

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

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

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

Кроме того, я обычно использую разные стили в Java для исключений времени выполнения и проверенных исключений, поскольку исключения времени выполнения адресованы программисту, который допустил ошибку. Поскольку исключения времени выполнения могут отображаться для конечных пользователей, я по-прежнему «держу его в чистоте», но они могут быть немного более краткими и загадочными. Проверенные сообщения об исключениях должны быть более полезными, поскольку может оказаться, что пользователь сможет решить проблему, если вы ее опишете (например, файл не найден, диск заполнен, нет маршрута к хосту и т. д.).

Одна вещь, которая полезна при отсутствии специального поля в исключении для информации, - это данные о нарушении:

throw new IndexOutOfBoundsException("offset < 0: " + off);

Я стараюсь встраивать свои сообщения об исключениях в сами исключения. Например. 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.

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