Мои Конспекты
Главная | Обратная связь

...

Автомобили
Астрономия
Биология
География
Дом и сад
Другие языки
Другое
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Металлургия
Механика
Образование
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Туризм
Физика
Философия
Финансы
Химия
Черчение
Экология
Экономика
Электроника

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





Помощь в ✍️ написании работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

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

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

 

 

 

 

границы" - 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);

}

 

 

 

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

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

 

Доверь свою работу ✍️ кандидату наук!
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой



Поиск по сайту:







©2015-2020 mykonspekts.ru Все права принадлежат авторам размещенных материалов.