Кто должен читать Exception.Message, если вообще?

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

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

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

Меня спросили, дают ли какой-либо из этих вопросов ответ на мой вопрос:

• Как написать хорошее сообщение об исключении
• Почему многие сообщения об исключениях не содержат полезных деталей?

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

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

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

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

Эти сообщения для других разработчиков

Ожидается, что эти сообщения будут прочитаны разработчиками, чтобы помочь им отладить приложение. Это может принимать две формы:

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

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

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

Например, IOSecurityExceptionтип исключения, сгенерированного при записи файла, не очень ясно описывает проблему: это потому, что у нас нет прав доступа к файлу? Или, может быть, мы можем прочитать это, но не написать? Или, может быть, файл не существует, и у нас нет прав для создания файлов там? Или, может быть, он заблокирован (надеюсь, тип исключения в этом случае будет другим, но на практике типы могут иногда быть загадочными). Или, возможно, Code Access Security не позволяет нам выполнять какие-либо операции ввода-вывода?

Вместо:

IOSecurityException: файл был найден, но в разрешении на чтение его содержимого было отказано.

гораздо более явный Здесь мы сразу знаем, что права доступа к каталогу установлены правильно (иначе мы не сможем узнать, существует ли файл), но разрешения на уровне файла проблематичны.

Это также означает, что если вы не можете предоставить какую-либо дополнительную информацию, которой нет в типе исключения, вы можете оставить сообщение пустым. DivisionByZeroExceptionхороший пример, когда сообщение является избыточным С другой стороны, тот факт, что большинство языков позволяют генерировать исключение без указания его сообщения, делается по другой причине: либо потому, что сообщение по умолчанию уже доступно, либо потому, что оно будет сгенерировано позже, если это необходимо (и генерация этого сообщения). сообщение заключено в тип исключения, что имеет смысл, говоря "OOPly" ).

Обратите внимание, что по техническим (часто из-за производительности) причинам некоторые сообщения оказываются гораздо более загадочными, чем должны быть. .NET's NullReferenceException:

В экземпляре объекта не задана ссылка на объект.

отличный пример сообщения, которое не помогает. Полезное сообщение будет:

Ссылка на объект productне установлена ​​на экземпляр объекта при вызове product.Price.

Эти сообщения не для конечных пользователей!

Конечные пользователи не должны видеть сообщения об исключениях. Никогда. Хотя некоторые разработчики заканчивают тем, что показывают эти сообщения пользователям, это приводит к плохому пользовательскому опыту и расстройству. Сообщения, такие как:

В экземпляре объекта не задана ссылка на объект.

для конечного пользователя абсолютно ничего не значит, и его следует избегать любой ценой.

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

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

• Запрещает пользователю привести приложение к исключительному случаю. Если вы попросите пользователя ввести два числа и разделить первое на второе, почему вы позволите пользователю ввести ноль во втором случае, чтобы обвинить его несколько секунд спустя? Как насчет выделения текстового поля красным цветом (с полезной подсказкой о том, что число должно отличаться от нуля) и отключения кнопки проверки, пока поле не останется красным?

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

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

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

  Деление на ноль произошло. [ХОРОШО]

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

  Поле D13 не может иметь значение, идентичное значению в поле E6, поскольку вычитание этих значений используется в качестве делителя. [ХОРОШО]

  или, может быть:

  Значения, сообщаемые службой ATP, не соответствуют локальным данным. Это может быть вызвано несинхронизацией локальных данных. Хотите синхронизировать информацию о доставке и повторить попытку? [Да нет]

Эти сообщения не для анализа

Сообщения об исключениях не должны анализироваться или использоваться программно. Если вы считаете, что вызывающей стороне может потребоваться дополнительная информация, включите ее в исключение рядом с сообщением. Это важно, потому что сообщение может быть изменено без уведомления. Тип является частью интерфейса, но сообщения нет: никогда не полагайтесь на него для обработки исключений.

Представьте себе сообщение об исключении:

Время ожидания подключения к серверу кэширования истекло после ожидания 500 мс. Либо увеличьте время ожидания, либо проверьте мониторинг производительности, чтобы определить падение производительности сервера. Среднее время ожидания кеширующего сервера составило 6 мс. за последний месяц 4 мс за последнюю неделю и 377 мс. за последний час.

Вы хотите извлечь значения «500», «6», «4» и «377». Подумайте немного о подходе, который вы будете использовать для анализа, и только потом продолжайте чтение.

У тебя есть идея? Отлично.

Теперь оригинальный разработчик обнаружил опечатку:

Connecting to the caching sever timed out after waiting [...]

должно быть:

                            ↓
Connecting to the caching server timed out after waiting [...]

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

Среднее время ожидания кеширующего сервера составило 6 мс. за последний месяц 5 мс за последние 24 часа 377 мс за последний час.

Что происходит с вашим разбором?

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

{
    message: "Connecting to the caching [...]",
    properties: {
        "timeout": 500,
        "statistics": [
            { "timespan": 1, "unit": "month", "average-timeout": 6 },
            { "timespan": 7, "unit": "day", "average-timeout": 4 },
            { "timespan": 1, "unit": "hour", "average-timeout": 377 },
        ]
    }
}

Насколько легко использовать эти данные сейчас?

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

Ответ на это полностью зависит от исключения.

Самый важный вопрос, который нужно задать, это "кто может решить проблему?" Если исключение вызвано ошибкой файловой системы при открытии файла, возможно, имеет смысл передать это сообщение конечному пользователю. Сообщение может содержать больше информации о том, как исправить ошибку. Я могу вспомнить один конкретный случай в моей работе, где у меня была система плагинов, которая загружала DLL. Если пользователь произвел опечатку в командной строке, чтобы загрузить неправильный плагин, основное сообщение об ошибке на самом деле содержало полезную информацию, позволяющую устранить проблему.

Однако в большинстве случаев необработанное исключение не может быть исправлено пользователем. Большинство из них связаны с внесением изменений в код. В этих случаях потребителем сообщения явно является разработчик.

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

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