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

Заметьте, после двух попыток (в общем случае 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 ? Она должна иметь вид:

{ ? } Rescuer { ? }

с заменой знаков вопроса соответствующими утверждениями. (Полезно, перед дальнейшим чтением постараться самостоятельно задать эти утверждения.)

Рассмотрим, прежде всего, предусловие для Rescue r . Любая попытка написать нечто не тривиальное будет ошибкой! Напомним, чем сильнее предусловие, тем проще работа программы. Любое предусловие для Rescue r ограничит число случаев, которыми должна управлять эта программа. Но она должна работать во всех ситуациях! Когда возникает исключение, ничего нельзя предполагать, - такова природа исключения. Нам не дано предугадать, когда компьютер даст сбой, или пользователю вздумается нажать клавишу "break".

Поэтому остается единственная возможность - предусловие для Rescue r равно True . Это самое слабое предусловие, удовлетворяющее всем состояниям и означающее, что Rescue r должна работать во всех ситуациях.

Для ленивого создателя Rescue r это "плохая новость", - тот случай, когда "заказчик всегда прав"!