Принцип отказа

Как отказаться сразу

Спаси и Повтори (Rescue и Retry)

Механизм исключений

Из предшествующего анализа следует механизм исключений, наилучшим образом соответствующий ОО-подходу и идеям Проектирования по Контракту.

Для обеспечения основных свойств введем в язык два новых ключевых слова. Для случаев, в которых необходим точно отрегулированный механизм, будет доступен библиотечный класс EXCEPTIONS.

Прежде всего, в тексте программы должна быть возможность указания действий, выполняемых при возникновении исключения. Для этой цели и вводится новое ключевое слово 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 ПовторениеO3

O2

O2

INTERVAL

EQUATION

EQUATION

integrate

solve (from GENERAL_EQUATION)

filter

interval_big_enough: Нарушено предусловие

Отказ программы

Отказ программы

Отказ

Отказ

Повторение

O2

O1(root)

MATH

INTERFACE

new_matrix (from BASIC_MATH)

make

enough_memory: Check Нарушение

Отказ программы

Отказ

Отказ

Таблица 12.1. Пример таблицы истории исключений

Эта таблица содержит историю не только тех исключений, которые привели, в конечном счете, к отказу системы, но и исключений, эффект которых был преодолен в результате выполнения rescue - retry. Число исключений в таблице может быть ограничено, например, числом 100 по умолчанию. Порядок в таблице сверху вниз является обратным порядку, в котором вызываются программы. Корневая процедура создания записана в последней строке таблицы.

Столбец Программа идентифицирует для каждого исключения программу, чей вызов был прерван исключением. Столбец Объект идентифицирует цель этого вызова; используемые здесь имена O1 и так далее, но в реальной трассировке они будут внутренними идентификаторами, позволяющие определить, являются ли объекты совпадающими. Столбец Класс указывает класс, генерирующий объект.

Столбец Природа Исключения указывает, что случилось. Здесь, как показано во второй сверху строке таблицы, могут использоваться метки утверждений, например, interval_big_enough, что позволяет точно идентифицировать нарушаемое предложение в программе.

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

Игнорируя такие промежуточные вызовы, - успешные и потому неинтересные для цели нашего обсуждения - здесь приведена цепочка вызовов и возвратов, соответствующая выше приведенной истории исключений. Для реконструкции действий следует следовать по стрелкам, обходя их против часовой стрелки, начиная от программы make, изображенной слева вверху.

Рис. 12.2. Выполнение, приведшее к отказу

Дата добавления: 2014-01-07