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

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

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

[x].Программа имеет два способа справиться с исключениями - Повторение вычислений ( Retry) и Организованная Паника. При Повторении тело программы выполняется заново. Организованная Паника означает отказ и формирование исключения у вызывающей программы.

[x].Формальная роль обработчика исключений, не заканчивающегося retry, состоит в восстановлении инварианта, но не в обеспечении контракта программы. Последнее всегда является делом тела программы (предложения do). Формальная роль ветви, заканчивающейся retry, состоит в восстановлении инварианта и предусловия, так чтобы тело программы могло попытаться в новой попытке выполнить контракт.

[x].Базисный механизм обработки исключений, включаемый в язык, должен оставаться простым, если только поощрять прямую цель обработки исключений - Организованную Панику или Повторение. Для приложений, нуждающихся в более тонком контроле над исключениями, доступен класс EXCEPTIONS , позволяющий добраться до свойств каждого вида исключений и провести их обработку. Этот класс позволяет создавать и обрабатывать исключения разработчика.

[Liskov 1979] и [Cristian 1985] предлагали другие точки зрения на исключения. Многие из работ по ПО, толерантному к отказам, ведут начало от понятия "восстанавливающий блок" [Randell 1975]. Такой блок используется в задаче, когда основной алгоритм отказывается выдавать решение. Этим "восстанавливающий блок" отличается от предложения rescue , которое никогда не пытается достичь основной цели, хотя и может повторно запустить выполнение, предварительно "залатав" все повреждения.

[Hoare 1981] содержит критику механизма исключений Ada.

Подход к обработке исключений, разработанный в этой лекции, был впервые представлен в [M 1988e] и [M 1988].

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

Несмотря на скептицизм, высказанный в разделе "Обсуждение" этой лекции по поводу рассматривания исключений как объектов, займитесь развитием этой идеи и обсудите, как мог бы выглядеть класс EXCEPTION , полагая, что экземпляры этого класса обозначают исключения, появившиеся при выполнении. Не путайте его с классом EXCEPTIONS , который доступен благодаря наследованию и обеспечивает общие свойства исключений. Попытайтесь, в частности, наряду с запросами, включить команды в разрабатываемый вами класс.

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

До сих пор, элементы ПО выражались полностью в ОО-нотации. Но программы появились задолго до распространения ОО-технологии. Часто возникает необходимость соединить объектное ПО с элементами, написанными, например, на языках С, Fortran или Pascal. Нотация должна поддерживать этот процесс.

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

ОО-системы состоят из классов, образованных компонентами (features), в частности, подпрограммами, содержащими инструкции. Что же является правильным уровнем модульности (granularity) для интегрирования внешнего программного продукта?

Конструкция должна быть общей - это исключает классы, существующие только в ОО-языках. Инструкции - слишком низкий уровень. Последовательность, в которой две ОО-инструкции окаймляют инструкцию на языке С:

-- только в целях иллюстрации

create x l make (clone (a))

(struct A) *x = &y; /* A piece of C */

x.display

трудно было бы понять, проверить, сопровождать.

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

Отсюда вытекает понятие внешней программы. Внешняя программа имеет большинство признаков нормальной программы: имя, список аргументов, тип результата, если это функция, предусловие и постусловие, если они уместны. Вместо предложения doона имеет предложение external, определяющее язык реализации. Следующий пример взят из класса, описывающего символьные файлы:

put (c: CHARACTER) is

-- Добавить c в конец файла.

require

write_open: open_for_write

external

"C" alias "_char_write";

ensure

one_more: count = old count + 1

end

Предложение aliasфакультативно и используется, только если оригинальное имя внешней программы отличается от имени, данного в классе. Это случается, когда внешнее имя недопустимо в ОО-нотации, например, имя, начинающееся с символа подчеркивания (используемое в языке С).

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

[x].Некоторые внешние программные элементы могут быть макросами. Они имеют вид подпрограмм в ОО-мире, но любой их вызов предполагает вставку тела макроса в точке вызова. Этого можно достичь вариацией имени языка (как, например, " C:[macro]...").