Должны ли вы сообщать текст сообщений об исключениях?

Рассмотрим некоторый код, который может генерировать проверенное исключение (исключение типа Exception). Конечно, ваш код catch является исключением. Вы не просто проглотили исключение, ваш код каким-то образом сообщает об этом пользователю через ваш пользовательский интерфейс. Возможно, в файле журнала или с помощью всплывающего окна с графическим интерфейсом.

Если текст, который вы сообщаете пользователю, включает текст сообщения об исключении. То есть текст, предоставленный Throwable.getMessage() или Throwable.getLocalizedMessage()?

Я думаю, что нет, но, похоже, многие со мной не согласны. Так что я не так понял? Мой аргумент заключается в следующем.

Сообщение было создано при возникновении исключения. Поэтому в лучшем случае он может предоставлять информацию только очень низкого уровня, которая может быть неприемлемой для сообщения пользователю.
С философской точки зрения использование сообщения кажется мне против всей точки исключения, которая заключается в том, чтобы отделить обнаружение и инициирование обработки ошибок (часть throw) от завершения обработки и создания отчетов (часть catch). Использование сообщения означает, что сообщение должно быть пригодным для создания отчетов, что переводит ответственность за отчетность в местоположение, которое должно отвечать только за обнаружение и инициирование. То есть, я бы сказал, что getMessage() часть дизайна Throwable была ошибкой.
Сообщение не локализовано. Несмотря на название, getLocalizedMessage() не очень хорош, потому что вы можете не знать, какую локаль вы хотите использовать, пока не сделаете исключение catch (это отчет для перехода в системный журнал, прочитанный вашими английскими системными администраторами, или это всплывающее окно для французского пользователя GUI?).
Я слышал, что в Java 7 значительно улучшена иерархия исключений для IOException, что позволяет вам обрабатывать различные виды ошибок ввода-вывода в разных предложениях catch, что делает текст getMessage() менее важным. Это подразумевает, что даже разработчикам на Java немного неудобно с getMessage().

Я не спрашиваю, полезна ли отчетность по трассировке стека. Трассировка стека будет полезна только для исключения, которое предполагает ошибку. То есть для неконтролируемого исключения. Я думаю, что в таких обстоятельствах предоставление низкоуровневой детализации сообщения об исключении не только полезно, но и обязательно. Но мой вопрос касается проверенных исключений, таких как file-not-found.

И я не спрашиваю о "наилучшей практике" для текста сообщения.

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

В некоторых проектах я делаю особый вид исключения (например, UserFriendlyException). Этот тип исключения должен иметь удобное для пользователя сообщение об ошибке. Если я поймаю такое исключение, я могу отобразить его пользователю.

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

Ответ 4

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