Стандартизуйте использование исключений в вашем проекте

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

Рассмотрите вопрос о централизованном выводе информации об исключениях

Выясните, какие исключения генерирует используемая библиотека

Избегайте пустых блоков catch

Вносите в описание исключения всю информацию о его причинах

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

Иногда возникает искушение оставить без внимания исключение, которое вы не знаете, как обработать. Например:

Плохой пример игнорирования исключения (Java)

try {

// много кода

} catch (AnException exception) {

}

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

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

Хороший пример игнорирования исключения на Java

try {

// много кода

} catch (AnException exception) {

LogError("Unexpected exception");

}

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

Вот пример упрощенного обработчика исключений. Он просто печатает диагностическое сообщение:

Пример централизованного генератора сообщений об исключениях, часть 1 (Visual Basic)

Sub ReportException(_

ByVal className, _ SXSTS^

ByVal thisException As Exception _

)

Dim message As String

Dim caption As String

message = "Exception: " & thisException.Message & "." & ControlChars.CrLf & _

"Class: " & className & ControlChars.CrLf &

"Routine: " & thisException.TargetSite.Name & ControlChars.CrLf

caption = "Exception"

MessageBox.Show(message, caption, MessageBoxButtons.OK,

MessageBoxIcon.Exclamation)

End Sub

Этот обработчик можно использовать следующим образом:

Пример централизованного генератора сообщений об исключениях, часть 2 (Visual Basic)

Try

…

Catch exceptionObject As Exception

ReportException(CLASS_NAME, exceptionObject)

End Try

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

Если вы решили создать централизованный генератор сообщений, примите во внимание основные проблемы с централизованной обработкой ошибок, обсуждаемые в подразделе «Вызвать процедуру или объект — обработчик ошибок».

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

¦ Если вы работаете с языком, таким как C++, который позволяет генерировать исключения разных типов, стандартизуйте, что конкретно будет создаваться.

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

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

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

¦ Определите конкретные случаи, в которых код может использовать синтаксис throw-catch для локальной обработки ошибок.

¦ Определите конкретные случаи, в которых код может сгенерировать исключение, не перехватываемое локально.

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

¦ Определите, допускаются ли исключения в конструкторах и деструкторах.

Рассмотрите альтернативы исключениям

Некоторые языки поддерживают исключения 5-10 лет и более. Однако до сих пор нет общепринятых правил их безопасного использования.

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

локальную обработку ошибок, возврат кода ошибки, запись отладочной информации в файл, прекращение работы системы и др. Обрабатывать ошибки с помощью исключений только потому, что это позволяет язык, — классический пример программирования на языке, а не с использованием языка (см. разделы 4.3 и 34.4).

И напоследок подумайте, действительно ли вашей программе необходимо обрабатывать исключения. Точка. Как заметил Бьерн Страуструп, иногда лучшей реакцией на серьезную ошибку периода выполнения будет освобождение всех ресурсов и прекращение работы. Пусть пользователь перезапустит программу с надлежащими входными данными (Stroustrup, 1997).

Изоляция повреждений, вызванных ошибками

Изоляция повреждений, или баррикада, — это стратегия, сходная с тем, как изолируются отсеки в трюме корабля. Если корабль налетает на айсберг и в днище появляется пробоина, отсеки задраиваются, и остальная часть корабля не страдает. Баррикады также аналогичны брандмауэрам, предотвращающим распространение огня из одной части здания в другую. (Ранее баррикады и назывались брандмауэрами, но сейчас термин «брандмауэр» обычно относится к блокировке нежелательного сетевого трафика.)

Один из способов изоляции в целях защитного программирования состоит в разработке набора интерфейсов в качестве оболочки для «безопасных» частей кода.

Проверяйте корректность данных, пересекающих границу безопасной области, и реагируйте соответственно, если данные неправильные (рис. 8-2).

Рис. 8-2. Выделение части кода для работы с непроверенными данными, а части —

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

Тот же подход применим и на уровне класса. Открытые методы класса предполагают, что данные небезопасны и отвечают за их проверку и исправление. Если данные были проверены открытыми методами класса, закрытые методы могут считать, что данные безопасны.

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

Дата добавления: 2014-01-07