Во-вторых, в целочисленной переменной не передашь много информации. Можно, конечно, обозначить ситуацию "аргумент отрицательный" как -1, ситуацию "аргумент слишком большой" как -2 и т.д. Но если аргумент слишком большой, я хотел бы знать, какой именно, поскольку это поможет мне найти источник проблемы. Однако в целочисленной переменной такую информацию не сохранишь.
В-третьих, проверка возвращаемого значения вовсе не обязательна. Чтобы понять, что я имею в виду, представьте себе, что кто-то написал функцию factorial( ), которая послушно проверяет, находится ли её аргумент в допустимых границах. Однако, если код, вызвавший эту функцию, не будет проверять возвращаемое значение, это не приведёт ни к чему хорошему. Конечно, я мог бы ввести в функцию всякие страшные угрозы наподобие "Вы обязательно должны проверить сообщения об ошибках, иначе...", но, думаю, не стоит объяснять, что язык не может никого ни к чему принудить.
Даже если моя функция проверяет наличие ошибки в factorial( ) или любой другой функции, что она может с ней сделать? Пожалуй, только вывести сообщение об ошибке ( которое я сам написал ) и вернуть другое значение, указывающее на наличие ошибки, вызывающей функцию, которая, скорее всего, повторит весь этот процесс. В результате программа будет переполнена кодом, подобным приведённому ниже.
errRtn = someFunc( ) ;
if ( errRtn )
{
errorOut( "Ошибка при вызове someFn( )" ) ;
return MY_ERROR_1
}
errRtn = someOtherFunc( ) ;
if ( errRtn )
{
errorOut( "Ошибка при вызове someOtherFn( )" ) ;
return MY_ERROR_1
}
Такой механизм имеет ряд недостатков.
■■■
■ Изобилует повторениями.
■ Заставляет программиста отслеживать множество разных ошибок и писать код для обработки всех возможных вариантов.
■ Смешивает код, отвечающий за обработку ошибок, с обычным кодом, что не добавляет ясности программе.
■■■
Эти недостатки кажутся безобидными в простом примере, но могут превратиться в большие проблемы, когда программа станет более сложной. В результате такой подход приводит к тому, что обработкой ошибок занимается 90% кода.
Механизм исключительных ситуаций позволяет обойти эти проблемы, отделяя код обработки ошибок от обычного кода. Кроме того, наличие исключений делает обработку ошибок обязательной. Если ваша функция не обрабатывает сгенерированное исключение, управление передаётся далее по цепочке вызывающих функций, пока С++ не найдёт функцию, которая обработает возникшую проблему. Это также даёт возможность игнорировать ошибки, которые вы не в состоянии обработать.
_________________
292 стр. Часть 5. Полезные особенности
►Механизм исключительных ситуаций...293
Познакомимся поближе с тем, как программа обрабатывает исключительную ситуацию. При возникновении исключения ( throw ) С++ первым делом копирует сгенерированный объект в некоторое нейтральное место. После этого просматривается конец текущего блока try.
Если блок try в данной функции не найден, управление передаётся вызывающей функции, где и осуществляется поиск обработчика. Если и здесь не найден блок try, поиск повторяется далее, вверх по стеку вызывающих функций. Этот процесс называется разворачиванием стека.
Важная особенность разворачивания стека состоит в том, что на каждом его этапе все объекты, которые выходят из области видимости, уничтожаются так же, как если бы функция выполнила команду return. Это оберегает программу от потери ресурсов и "праздно шатающихся" неуничтоженных объектов.
Когда необходимый блок try найден, программа ищет первый блок catch ( который должен находиться сразу за закрывающей скобкой блока try ). Если тип сгенерированного объекта совпадает с типом аргумента, указанным в блоке catch, управление передаётся этому блоку; если же нет, проверяется следующий блок catch. Если в результате подходящий блок не найден, программа продолжает поиск уровнем выше, пока не будет обнаружен необходимый блок catch. Если искомый блок не обнаружен, программа аварийно завершается. Рассмотрим приведённый ниже пример.