Опубликован: 17.10.2005 | Доступ: свободный | Студентов: 7956 / 285 | Оценка: 4.38 / 4.10 | Длительность: 41:16:00
ISBN: 978-5-7502-0255-3
Специальности: Программист
Лекция 12:

Когда контракт нарушается: обработка исключений

Обсуждение

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

Давайте рассмотрим несколько альтернативных идей проектирования, которым можно было бы следовать, и обсудим, почему они были опущены.

Дисциплинированные исключения

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

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

Исключения в языках Ada, CLU, PL/1 не следуют этой модели. В языке Ada ее инструкция

Raise exc

прервет выполнение программы и возвратит управление вызывающей программе, которая может обработать исключение в специальном обработчике, или вернет управление на уровень выше. Но здесь нет правила, ограничивающего действия обработчика. Следовательно, полностью возможно игнорировать исключение или вернуть альтернативный результат. Это объясняет, почему некоторые разработчики смотрят на механизм исключений просто как на средство обработки специальных случаев, не включенных в основной алгоритм. Такие приложения исключения рассматривают фактически raise как goto, что, очевидно, опасно, так как позволяет передавать управление за границы программы. По моему мнению, они злоупотребляют механизмом.

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

Должны ли исключения быть объектами?

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

В ОО-расширении Pascal в среде Delphi исключения действительно представлены объектами.

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

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

Методологическая перспектива

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

Ключевые концепции

  • Обработка исключений - это механизм, позволяющий справиться с неожиданными условиями, возникшими в период выполнения.
  • Отказ - это невозможность во время выполнения программы выполнить свой контракт.
  • Программа получает исключение в результате: отказа вызванной ею программы, нарушения утверждений, сигналов аппаратуры или операционной системы об аномалиях, возникших в ходе их работы.
  • Программная система может включать также исключения, спроектированные разработчиком.
  • Программа имеет два способа справиться с исключениями - Повторение вычислений ( Retry ) и Организованная Паника. При Повторении тело программы выполняется заново. Организованная Паника означает отказ и формирование исключения у вызывающей программы.
  • Формальная роль обработчика исключений, не заканчивающегося retry, состоит в восстановлении инварианта, но не в обеспечении контракта программы. Последнее всегда является делом тела программы (предложения do ). Формальная роль ветви, заканчивающейся retry, состоит в восстановлении инварианта и предусловия, так чтобы тело программы могло попытаться в новой попытке выполнить контракт.
  • Базисный механизм обработки исключений, включаемый в язык, должен оставаться простым, если только поощрять прямую цель обработки исключений - Организованную Панику или Повторение. Для приложений, нуждающихся в более тонком контроле над исключениями, доступен класс EXCEPTIONS, позволяющий добраться до свойств каждого вида исключений и провести их обработку. Этот класс позволяет создавать и обрабатывать исключения разработчика.

Библиографические замечания

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

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

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

Упражнения

У12.1 Наибольшее целое

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

У12.2 Объект Exception

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

Александр Шалухо
Александр Шалухо
Анатолий Садков
Анатолий Садков

При заказе pdf документа с сертификатом будет отправлен только сертификат или что-то ещё?