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

Что можно сказать о постусловии Rescue r ? Напомню, эта часть предложения rescueведет к отказу, но, прежде чем передать управление клиенту, необходимо восстановить стабильное состояние. Это означает необходимость восстановления инварианта класса.

Отсюда следует правило, в котором уже больше нет знаков вопросов:

Правило корректности для включающего отказ предложения rescue

4.

{True} Rescuer {INV}

Похожие рассуждения дают правило для Retry r - части предложения rescue , включающей ветви, приводящие к инструкции retry :

Правило корректности для включающего повтор предложения rescue

5.

{True} Retryr {INV and prer }

Интересно сравнить формальные роли тела и предложения Rescue r :

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

{True} Rescuer {INV}

Входное утверждение сильнее для Body r - в то время, когда Rescue r не накладывает никаких требований, перед началом выполнение тела программы (предложения do) должно выполняться предусловие и инвариант. Это упрощает работу Body r .

Выходное утверждение также сильнее для Body r - в то время, когда Rescue r обязана восстановить только инвариант класса, Body r обязана сыграть свою роль и обеспечить истинность выполнения постусловия. Это делает ее работу более трудной.

Эти правила отражают разделение ролей между предложением doи предложением rescue. Задача тела обеспечить выполнение контракта программы, не управляя непосредственно исключениями. Задача rescue- управлять обработкой исключениями, возвращая управление либо телу программы, либо вызывающей программе. Но в обязанности rescue не входит обеспечение контракта.

Формализовав роль предложения rescue, вернемся к рассмотрению ситуации, когда это предложение отсутствует в программе. Правило для этого случая было введено ранее, но с обязательством его уточнения. Ранее полагалось, что отсутствующее предложение rescueэквивалентно присутствию пустого предложения ( rescue end). В свете наших формальных правил это не всегда является приемлемым решением. Правило (3) требует:

{True} Rescuer {INV}

Если Rescue r является пустой инструкцией, а инвариант не тождественен True , то правило не выполняется.

Зададим точное правило. Класс Any является корневым классом - прародителем всех классов. В состав этого класса включена процедура default_rescue , наследуемая всеми классами - потомками Any :

default_rescue is

-- Обрабатывает исключение, если нет предложения rescue.

-- (По умолчанию: ничего не делает)

do

end

Программа, не имеющая предложения rescue, рассматривается теперь как эквивалентная программе с предложением rescue в следующей форме:

rescue

default_rescue

Каждый класс может переопределить default_rescue , для выполнения специфических действий, гарантирующих восстановление инварианта класса, вместо эффекта пустого действия, заданного по умолчанию в GENERAL . Механизм переопределения компонент класса будет изучаться в последующих лекциях, посвященных наследованию.

Вы, конечно, помните, что одна из ролей процедуры создания состоит в производстве состояния, удовлетворяющего инварианту класса INV . Отсюда понятно, что во многих случаях переопределение default_rescue может основываться на использовании процедур создания.

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

[x].Возможно, требуется определить природу последнего исключения, чтобы разными исключениями управлять по-разному.

[x].Возможно, требуется запретить включение исключений для некоторых сигналов.

[x].Возможно, вы захотите включать собственные исключения.

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