Бертран Мейер - Основы объектно-ориентированного программирования

do

"Декодировать запрос пользователя"

"Выполнить подходящую команду в ответ на запрос"

rescue

message ("Извините, эта команда отказала")

message ("Пожалуйста, попробуйте использовать другую команду")

message ("Пожалуйста, сообщите об отказе автору")

"Команды, латающие состояние редактора"

retry

end

Эта схема предполагает на практике, что поддерживаемые запросы пользователя включают: "сохранить текущее состояние работы" , "завершить работу" . Оба последних запроса должны работать корректно. Пользователь, получивший сообщение "Извините..." , несомненно, захочет сохранить работу и выйти как можно скорее. Некоторые из программ, реализующих команды редактора, могут иметь собственные предложения rescue , хотя и приводящие к отказу, но предварительно выдающие более информативные сообщения.

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

В основе N-версионного программирования лежит идея избыточности, доказавшая свою полезность в аппаратуре. В критически важных областях зачастую применяется дублирование аппаратуры, например, несколько компьютеров выполняют одни и те же вычисления, и есть компьютер-арбитр, сравнивающий результаты, и принимающий окончательное решение, если большинство компьютеров дало одинаковый результат. Этот подход хорошо защищает от случайных отказов в аппаратуре отдельного устройства. Он широко применяется в аэрокосмической области. (Известен случай, когда при запуске космического челнока сбой произошел в компьютере-арбитре). N-версионное программирование переносит этот подход на разработку ПО в критически важных областях. В этом случае создаются несколько программистских команд, каждая из которых независимо разрабатывает свою версию системы (программы). Предполагается, что ошибки, если они есть, будут у каждой команды свои.

Это спорная идея; возможно, лучше вложить средства в одну версию, добиваясь ее корректности, чем финансировать две или три несовершенных реализации. Проигнорируем, однако, эти возражения, пусть о полезности идеи судят другие. Нас будет интересовать возможность использования механизма retry в ситуации, где есть несколько реализаций, и используется первая из них, не заканчивающаяся отказом:

do_task is

-- Решить проблему, применяя одну из нескольких возможных реализаций.

require

...

local

attempts: INTEGER

do

if attempts = 0 then

implementation_1

elseif attempts = 1 then

implementation_2

end

ensure

...

rescue

attempts := attempts + 1

if attempts < 2 then

"Инструкции, восстанавливающие стабильное состояние"

retry

end

end

Обобщение на большее, чем две, число реализаций очевидно.

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

Заметьте, после двух попыток (в общем случае n попыток) предложение rescue достигает конца, не вызывая retry, следовательно, приводит к отказу.

Давайте рассмотрим более тщательно, что случается, когда включается исключение во время выполнения r . Нормальное выполнение (тела) останавливается; вместо этого начинает выполняться предложение rescue. После чего могут встретиться два случая:

[x].Предложение rescueвыполнит в конечном итоге retry. В этом случае начнется повторное выполнение тела программы. Эта новая попытка может быть успешной, тогда программа нормально завершится и управление вернется к клиенту. Вызов успешен, контракт выполнен. За исключением того, что вызов мог занять больше времени, никакого другого влияния появление исключения не оказывает. Если, однако, повторная попытка снова приводит к исключению, то вновь начнет работать предложение rescue.

[x].Если предложение rescueне выполняет retry, оно завершится естественным образом, достигнув end. (В последнем примере это происходит, когда attempts >=2 .) В этом случае программа завершается отказом; она возвращает управление клиенту, сигнализируя о неудаче выбрасыванием исключения. Поскольку клиент должен обработать возникшее исключение, то снова возникают два рассмотренных случая, теперь уже на уровне клиента.

Этот механизм строго соответствует принципу Дисциплинированной Обработки Исключения. Программа завершается либо успехом, либо отказом. В случае успеха ее тело выполняется до конца и гарантирует выполнение постусловия и инварианта. Когда выполнение прерывается исключением, то можно либо уведомить об отказе, либо попытаться повторно выполнить нормальное тело. Но нет никакой возможности выхода из предложения rescue , уведомив клиента, что все завершилось нормально.

Последний комментарий позволяет нам продвинуться в лучшем понимании механизма исключений, обосновав теоретическую роль предложения rescue. Формальные рассуждения помогут получить полную картину.

Формальное определение корректности класса выдвигает два требования к компонентам класса. Первое (1) требует, чтобы процедуры создания гарантировали корректную инициализацию - выполнение инварианта класса. Второе (2) напрямую относится к нашему обсуждению, требуя от каждой программы, запущенной при условии выполнения предусловия и инварианта класса, выполнения в завершающем состоянии постусловия и инварианта класса. Диаграмма, описывающая жизненный цикл объекта, отражает эти требования:

Рис. 12.3. Жизнь объекта

Формально правило (2) говорит:

3.

Для каждой экспортируемой программы r и любого множества правильных аргументов x r

{prer (xr) and INV} Bodyr {postr (xr) and INV}

Для простоты позвольте в дальнейшем рассмотрении игнорировать аргументы x r .

Пусть Rescue r обозначает ту часть предложения rescue , в которой игнорируются все ветви, ведущие к retry, другими словами в этой части сохраняются все ветви, доходящие до конца предложения rescue. Правило (2) задает спецификацию для программ тела - Body r . Можно ли получить такую же спецификацию для Rescue r ? Она должна иметь вид: