Цепочка вызовов
Обсуждая механизм обработки исключений, полезно иметь ясную картину последовательности вызовов, приведших в итоге к исключению. Это понятие уже появлялось при рассмотрении механизма языка Ada.
Рис. 12.1. Цепочка вызовов
Пусть r0 будет корневой процедурой некоторой системы (в Ada это программа main). В каждый момент выполнения есть текущая программа, вызванная последней и ставшая причиной исключения. Пройдем по цепочке в обратном порядке, начиная с текущей программы, от вызываемой к вызывающей программе. Реверсная цепочка (r0, последняя вызванная r0 программа r1, последняя вызванная r1 программа r2 и так далее до текущей программы) называется цепочкой вызовов.
Если возникает исключение, то для его обработки, возможно, придется подняться по цепочке, пока не будет достигнута программа, способная справиться с исправлением ситуации. Этот процесс заканчивается, когда достигнута программа r0 и не найден нужный обработчик исключения.
Механизм исключений
Из предшествующего анализа следует механизм исключений, наилучшим образом соответствующий ОО-подходу и идеям Проектирования по Контракту.
Для обеспечения основных свойств введем в язык два новых ключевых слова. Для случаев, в которых необходим точно отрегулированный механизм, будет доступен библиотечный класс EXCEPTIONS.
Спаси и Повтори (Rescue и Retry)
Прежде всего, в тексте программы должна быть возможность указания действий, выполняемых при возникновении исключения. Для этой цели и вводится новое ключевое слово rescue, задающее предложение с описанием действий, предпринимаемых для восстановления ситуации. Поскольку предложение rescue описывает действия, предпринимаемые при нарушении контракта, то разумно поместить его в конце программы после всех других предложений:
routine is
require
precondition
local
... Объявление локальных сущностей ...
do
body
ensure
postcondition
rescue
rescue_clause
end
Предложение rescue_clause является последовательностью инструкций. При возникновении исключения в теле программы вычисление прерывается, и управление передается предложению rescue. Хотя есть только одно такое предложение на программу, но в нем можно проанализировать причину исключения и нужным образом реагировать на различные события.
Другой новой конструкцией является инструкция retry, записываемая просто как retry. Эта инструкция может появляться только в предложении rescue. Ее выполнение состоит в том, что она повторно запускает тело программы с самого начала. Инициализация, конечно, не повторяется.
Эти конструкции являются прямой реализацией принципа Дисциплинированной Обработки Исключений. Инструкция retry обеспечивает механизм повторения; предложение rescue, не заканчивающееся retry приводит к отказу.
Как отказаться сразу
Последнее высказывание достойно возведения в ранг принципа.
Принцип отказа
Завершение выполнения предложения rescue, не включающее инструкции retry, приводит к тому, что вызов программы завершается отказом.
Так что, если и были вопросы, как на практике возникает отказ (ситуация (4) в классификации исключений), то это делается именно так, - при завершении предложения rescue.
В качестве специального случая рассмотрим программу, не имеющую предложения rescue. На практике именно этот случай характерен для огромного большинства программ. В разрабатываемом подходе к обработке исключений лишь избранные из поставляемых программ должны иметь такое предложение. Игнорируя объявления и другие части программы, можно полагать, что программа без предложения rescue имеет вид:
routine is
do
body
end
Тогда, приняв, как временное соглашение, что отсутствие предложения rescue эквивалентно существованию пустого предложения rescue, наша программа эквивалента программе:
routine is
do
body
rescue
-- Здесь ничего (пустой список инструкций)
end
Из принципа Отказа вытекают следующие следствия: если исключение встретилось в программе, не имеющей предложения rescue, то эта программа вырабатывает отказ, включая исключение у вызывающей программы.
| Рассмотрение отсутствующего предложения rescue, как присутствующего пустого предложения, является подходящей аппроксимацией на данном этапе рассмотрения. Но нам придется слегка подправить это правило, когда начнем рассматривать эффект исключений на инвариант класса. |
Таблица истории исключений
Если в программе произошел отказ, то ли из-за отсутствия предложения rescue, то ли потому, что это предложение закончилось без retry, она прервет выполнение вызывающей программы, вызвав в ней исключение типа (4) - отказ в вызываемой программе. Вызывающая программа столкнется с теми же самыми двумя возможностями: либо в ней есть предложение rescue, способное исправить ситуацию, либо она выработает отказ и передаст управление вверх по цепочке вызовов. Если на всем пути не найдется программы, способной справиться с исключением, то выполнение всей системы закончится отказом. В этом случае окружение должно сформировать и вывести ясную картину произошедшего - таблицу истории исключения. Вот пример такой таблицы:
| Объект | Класс | Программа | Природа исключения | Эффект |
|---|---|---|---|---|
| O4 | Z_Function | split (from E_FUNCTION) | Feature interpolate: Вызывалаcь ссылкой void | Повторение |