Должны ли вы сообщить текст сообщения об исключениях? - PullRequest
10 голосов
/ 06 сентября 2011

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

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

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

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

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

Ответы [ 4 ]

7 голосов
/ 06 сентября 2011

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

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

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

5 голосов
/ 06 сентября 2011

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

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

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

4 голосов
/ 06 сентября 2011

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

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

0 голосов
/ 15 ноября 2013

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

...