Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Обработка ошибок и исключения



главе...

Зачем нужен новый механизм обработки ошибок Механизм исключительных ситуаций

Так что же мы будем бросать?

 

знаю, как трудно с этим смириться, но факт остается фактом:  иногда  функ- ции работают неправильно. И не только мои. Традиционно вызывающей программе сообщается об ошибке посредством возвращаемого функцией значения. Однако язык C++ предоставляет новый, улучшенный механизм выявления и  обра- ботки ошибок с помощью исключительных или исключений (exceptions). Ис- ключение — это отступление от общего правила, т.е. случай, когда то или иное  пра- вило либо принцип неприменимы. Можно дать и такое определение: исключение — это неожиданное (и, надо полагать, нежелательное) состояние, которое возникает во

время выполнения программы.

Механизм исключительных ситуаций базируется на ключевых словах tr y (попытаться), (бросить) и catc h (поймать). В общих чертах этот механизм ра- ботает так: функция пытается выполнить фрагмент кода. Если в коде содержится ошибка, она бросает (генерирует) сообщение об ошибке, которое должна поймать (перехватить) вызывающая функция.

Это продемонстрировано в приведенном ниже фрагменте.

 

 

//factorial — вычисляет факториал int n)

{

//      функция не может работать с

//           п, мы сразу проверяем

// допустимость переданного аргумента if (л <

(

"Отрицательный

}

// теперь вычислим факториал int accum 1;

> 0]

{

п;

 

}

return

 

int              argcs, char*

{

Глава 27. Обработка ошибок и исключения                                           299


try{

// Эта строка генерирует исключение

<< "Factorial of -1 is "

<<           «

// Управление никогда не дойдет до этой строки cout << "Factorial of 10 is "

<<          << endl;

 

 

// Управление будет передано сюда catch (char* pError) {

cout << "Возникла     " <<   << endl;

)

return 0;

}

начинается с блока, выделенного ключевым словом try . В этом

блоке выполнение кода ничем не отличается от выполнения вне блока. В данном слу- чае () пытается вычислить факториал отрицательного числа. Однако функцию factoria l (} не так легко одурачить, поскольку она достаточно умно написана и об- наруживает, что запрос некорректен. При этом она генерирует сообщение об ошибке с помощью ключевого слова throw. Управление передается фрагменту, находящемуся сразу за закрывающей фигурной скобкой блока tr y и отвечающему за перехват сооб- щения об ошибке.

 

Зачем         новыймеханизм

Что плохого в методе возврата ошибки, подобном применяемому в FORTRAN? Факториал не может быть отрицательным, поэтому я мог бы сказать что-то вроде: "Если функция factoria l () обнаруживает ошибку, она возвращает отрицательное число. Значение отрицательного числа будет указывать на источник проблемы". Чем же плох такой метод? Ведь так было всегда.

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

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

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

В-третьих, проверка возвращаемого значения вовсе не обязательна. Чтобы  по- нять, что я имею в виду, представьте себе, что кто-то  написал  функцию (), которая послушно проверяет, находится ли ее аргумент в допустимых

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

 


Поделиться:



Последнее изменение этой страницы: 2019-04-19; Просмотров: 168; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.012 с.)
Главная | Случайная страница | Обратная связь