В описание исключения добавляйте информацию о сб ое

Если выполнение программы завершается аварийно из-за необработанного иск­лючения, система автоматически распечатывает трассировку стека для этого исключе­ния. Трассировка стека содержит строковое представление данного исключения, результат вызова его метода toString. Обычно это представление состоит из названия класса исключения и описания исключения (detail message). Часто это единственная информация, с которой приходится иметь дело программистам или специалистам по наладке, исследующим сбой программы. И если воспроизвести этот сбой нелегко, то получить какую-либо еще информацию будет трудно или даже вообще невозможно. Поэтому крайне важно, чтобы метод toString в классе исключения возвращал как можно больше информации о причинах отказа. Иными словами, строковое представ­ление исключения должно зафиксировать отказ для последующего анализа.

Для фиксации сбоя строковое представление исключения должно содержать значения всех параметров и полей, "способствовавших появлению этого исключе­ния". Например, описание исключения IndexOutOfBounds должно содержать нижнюю границу, верхнюю границу и действительный индекс, который .не уложился в эти границы. Такая информация говорит об отказе очень многое. Любое из трех значений или все они вместе могут быть неправильными. Представленный индекс может ока­заться на единицу меньше нижней границы или быть равен верхней границе ("ошибка

 

 

171

 

 

границы" - fencepost error) либо может иметь несуразное значение, как слишком маленькое, так и слишком большое. Нижняя граница может быть больше верхней (серьезная ошибка нарушения внутреннего инварианта). Каждая из этих ситуаций указывает на свою проблему, и если программист знает, какого рода ошибку следует искать, это в огромной степени облегчает диагностику.

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

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

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

 

/**

* Конструируем IndexOutOfBoundsException

* @ра ram lowerBound – самое меньшее из разрешенных значений индекса

 * @ param upperBound – самое большее из разрешенных значений индекса плюс один

* @ра r а m index – действительное значение индекса

*/

Public IndexOutOfBoundsExoeption(int lowerBound, int index) {

// Генерируем описание исключения,

// фиксирующее обстоятельства отказа

super( "Lower bound: " + lowerBound +

“,Upper bound: " + uppe rBound +

    “,Index: "     + index); 

}

 

172

 

 

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

Как отмечалось в статье 40, возможно, имеет смысл, чтобы исключение предо­ставляло методы доступа к информации об обстоятельствах сбоя (в представленном выше примере это lowerBound, upperBound и Index). Наличие таких методов доступа для обрабатываемых исключений еще важнее, чем для необрабатываемых, поскольку информация об обстоятельствах сбоя может быть полезна для восстановления работо­способности программы. Программный доступ к деталям необрабатываемого исключе­ния редко интересует программистов (хотя это и не исключено). Однако, согласно общему принципу (статья 9), такие методы доступа имеет смысл создавать .даже для необрабатываемых исключений.

 

⇐ Предыдущая32333435363738394041Следующая ⇒

Поделиться: