учебники, программирование, основы, введение в,
Ломбард автомобилей Новосибирск смотрите на www.avtolombard54.ru.

 

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

Базисные концепции обработки исключений
Литература по обработке исключений зачастую не очень точно определяет, что вызывает исключение. Как следствие, механизм исключений, представленный в таких языках программирования как PL/I и Ada, часто неправильно используется: вместо того, чтобы резервироваться только для истинно чрезвычайных ситуаций, они заканчивают службу как внутрипрограммные инструкции goto, нарушающие принцип Защищенности.
К счастью, теория Проектирования по Контракту, введенная в предыдущей лекции, обеспечивает хорошие рамки для точного определения включаемых концепций.
Отказы
Неформально исключение это аномальное событие, прерывающее выполнение программы. Для получения содержательного определения полезно вначале рассмотреть понятие отказа, непосредственно следующее из идеи контракта.
Программа это не произвольная последовательность инструкций, а реализация некоторой спецификации - контракта программы. Всякий вызов программы должен завершаться в состоянии, удовлетворяющем постусловию и инварианту класса. Неявное следствие контракта - при вызове программы не должны появляться прерывания операционной системы, связанные, например, с обращением к недоступным областям памяти или переполнением при выполнении арифметических операций.
Так должно быть, но в жизни не все происходит так, как должно быть. И мы должны ожидать, что рано или поздно при очередном вызове программы она не сможет выполнить свой контракт. Произойдет системное прерывание, или будет вызвана программа в состоянии, не удовлетворяющем ее предусловию, или в заключительном состоянии будет нарушено постусловие либо инвариант (в двух последних случаях предполагается мониторинг утверждений в период выполнения).
Такие ситуации будем называть отказом (failure).
Определения: успех, отказ
Вызов программы успешен, если он завершается в состоянии, удовлетворяющем контракту. Вызов завершается отказом, если он не успешен.
Будем использовать термины "отказ программы" или просто "отказ", как сокращения более точного термина "вызов программы, завершающийся отказом". Понятно, что сама программа не может быть ни успешной, ни давать отказ. Эти понятия применимы только по отношению к конкретному вызову.
Исключения
Вооружившись понятием отказа, можно теперь определить понятие "исключение". Программа приводит к отказу из-за возникновения некоторых специфических событий (арифметического переполнения, нарушения спецификаций), прерывающих ее выполнение. Такие события и являются исключениями.
Определение: исключение
Исключение - событие периода выполнения, которое может стать причиной отказа программы.
Зачастую исключение будет причиной отказа. Но можно предотвратить отказ, написав программу так, что она будет захватывать возникшее исключение, пытаться восстановить состояние, допускающее нормальное продолжение вычислений. Вот почему отказ и исключение - это разные понятия: каждый отказ это следствие исключения, но не каждое исключение приводит к отказу.
Изучение программных аномалий в предыдущей лекции привело к появлению терминов неисправность (fault) - для событий, приводящих к пагубным последствиям при выполнении программы, дефект (defect) - неадекватность программной системы, способная привести к отказам, ошибка (error) - неверные решения разработчика или проектировщика, приводящие к дефектам. Отказ - это неисправность; исключение, зачастую, тоже неисправность, но таковым не является, если его возможное появление предвиделось, и программа может справиться с возникшей ситуацией.
Источники исключений
Исключения можно классифицировать, разделив их на категории.
Определение: исключительные ситуации
Исключения могут возникать при выполнении программы r в результате следующих ситуаций.

  1. Попытка квалифицированного вызова a.f и обнаружение, что a = Void.
  2. Попытка присоединить значение Void к развернутой (expanded) цели.
  3. Выполнение невозможной или запрещенной операции, обнаруживаемое аппаратно или операционной системой.
  4. Вызов программы, приводящей к отказу.
  5. Предусловие r не выполняется на входе.
  6. Постусловие r не выполняется на выходе.
  7. Инвариант класса не выполняется на входе или выходе.
  8. Инвариант цикла не выполняется в результате инициализации в предложении from или после очередной итерации тела цикла.
  9. Итерация тела цикла не уменьшает вариант цикла.
  10. Не выполняется утверждение инструкции check.
  11. Выполнение инструкции, явно включающей исключение.

Случай (1) отражает одно из основных требований к использованию ссылок: вызов a.f имеет смысл, когда к a присоединен объект, другими словами, когда a не void. Это обсуждалось в при рассмотрении динамической модели.
Случай (2) также имеет дело с void значениями. Напомним, что "присоединение" (attachment) покрывает присваивание и передачу аргументов, имеющих одинаковую семантику. В разделе "Гибридное присоединение"отмечалась возможность присваивания ссылки развернутой цели, в результате чего происходит копирование объекта. Но это предполагает существование объекта, но если источник void, то присоединение вызовет исключение.
Случай (3) следствие сигналов, посылаемых приложению операционной системой.
Случай (4) возникает при отказе программы, как результат возникновения в ней исключения, с которым она не смогла справиться. Более подробно это будет рассмотрено ниже, но пока обратите внимание на правило, вытекающее из (4):
Отказы и исключения
Отказ программы - причина появления исключения в вызывающей программе.
Случаи (5)-(10) могут встретиться только при мониторинге утверждений, включенных на соответствующем уровне: assertion (require) для (5), assertion (loop) для (8) и (9) и так далее.
Случай (11) предполагает вызов процедуры raise, выбрасывающей (зажигающей) исключения. Такая процедура будет рассмотрена чуть позднее.
Ситуации отказа
Рассматривая список возможных исключений, полезно определить, когда может встретиться отказ (причина исключения у вызывающей программы):
Определение: случаи отказа
Вызов программы приводит к отказу, если и только если встретилось исключение в процессе выполнения, и программа не смогла с ним справиться.
Определения отказа и исключения взаимно рекурсивны: отказ возникает из-за появления исключений, а одна из причин исключения - отказ при вызове программы (случай (4)).

Обработка исключений

Теперь у нас есть определение того, что может случиться, - исключения - и того, с чем мы бы не хотели столкнуться в результате появления исключения, - отказа. Давайте разыскивать способы справляться с исключениями так, чтобы не возникли отказы. Что может сделать программа, когда ее выполнение прервано из-за нежелательного поведения?
Помощь в нахождении разумного ответа могут дать примеры того, как не следует поступать в подобных ситуациях. Ими мы обязаны механизму сигналов языка C, пришедшему из Unix, и одному учебнику по языку Ada.
Как не следует делать это - C-Unix пример
Первым контрпримером механизма (наиболее полно представленным в Unix, но доступным и на других платформах, реализующих C) является процедура signal, вызываемая в следующей форме:
signal (signal_code, your_routine)

с эффектом вызова обработчика исключения - программы your_routine, когда выполнение текущей программы прерывается, выдавая соответствующий код сигнала (signal_code). Код сигнала - целочисленная константа, например, SIGILL (неверная инструкция - illegal instruction) или SIGFPE (переполнение с плавающей точкой - floating-point exception). В программу можно включить сколь угодно много вызовов процедуры signal, что позволяет обрабатывать различные, возможные ошибки.
Теперь предположим, что при выполнении некоторой инструкции произошло прерывание и выработан соответствующий код сигнала. Будет или нет вызвана процедура signal, но выполнение программы завершается в не нормальном состоянии. Предположим, что вызывается обработчик события - your_routine, пытающийся исправить ситуацию. Беда в том, что, завершив работу, он возвращает управление непосредственно в точку, где произошло прерывание (в не нормальное состояние). Это опасно, вероятнее всего, из этой точки невозможно нормально продолжить работу.
Что необходимо в большинстве подобных случаев - исправить ситуацию и продолжить выполнение, начиная с некоторой особой точки, но не точки прерывания. Мы увидим, что есть простой механизм, реализующий эту схему. Заметьте, он может быть реализован и на C, на большинстве платформ. Достаточно комбинировать процедуру signal с двумя другими библиотечными процедурами: setjmp, вставляющую маркер в точку, допускающую продолжение вычислений, и longjmp для возврата к маркеру. С механизмом setjmp-longjmp следует обращаться весьма аккуратно. Поэтому он не ориентирован на обычных программистов, но может использоваться разработчиками компиляторов для реализации высокоуровневого механизма ОО-исключений, который будет описан в этой лекции.
Как не следует делать это - Ada пример
Приведу пример программы, взятый из одного учебникапо языку Ada.
sqrt (x: REAL) return REAL is
begin
if x < 0.0 then
raise Negative
else
normal_square_root_computation
end
exception
when Negative =>
put ("Negative argument")
return
when others => ...
end -- sqrt

Этот пример, вероятно, предназначался для синтаксической иллюстрации механизма Ada, и был написан быстро (он, например, отказывается возвращать значение в случае возникновения исключения). Поэтому было бы непорядочно критиковать его, как если бы это был настоящий пример хорошего программирования. Вместе с тем, он ясно показывает нежелательный способ обработки исключений. Поскольку Ada ориентирована на военные и космические приложения, то остается надеяться, что ни одна из реальных программ не следует буквально этой модели.
Целью программы является получение вещественного квадратного корня из вещественного числа. Но что если число отрицательно? В языке Ada нет утверждений, так что в программе проводится проверка, возбуждающая исключение для отрицательных чисел.
Инструкция raise Exc прерывает выполнение текущей программы и включает исключение с кодом Exc. Это исключение может быть захвачено и обработано при наличии предложений exception, имеющих вид:
exception
when code_a1, code_a2, ...=> Instructions_a;
when code_b1, ... => Instructions_b;
...

Если код исключения совпадает с одним из кодов, указанных в части when, то выполняются соответствующие инструкции. Если, как в примере, есть предложение when others, то его инструкции выполняются, когда код исключения не совпадает ни с одним из кодов предыдущих частей when. Если нет универсального обработчика when others, и код исключения не совпадает ни с одним кодом, то поиск обработчика будет вестись у вызывающей программы, если вызывающей программы нет, то достигнута программа main и программа завершается отказом.
В примере нет необходимости переходить к вызывающей программе, поскольку выброшенное исключение с кодом Negative захватывается обработчиком с таким же кодом.
Но что делают соответствующие инструкции? Посмотрите еще раз:
put ("Negative argument")
return

Напечатается сообщение - довольно глубокомысленное, а затем управление перейдет к вызывающей программе, которая, не будучи уведомлена о событии, продолжит свое выполнение, как если бы ничего не случилось. Вспоминая снова о типичных приложениях Ada, можно лишь надеяться, что этой схеме не следует артиллерийское приложение, в результате которой снаряды могут упасть на головы совсем не тех солдат, для которых вряд ли может служить утешением посланное сообщение об ошибке.
Эта техника, вероятно, хуже, чем C-Unix сигнальный механизм, позволяющий, по крайней мере, возобновить вычисление в точке, где оно остановилось. Обработчик исключения when, заканчивающийся инструкцией return, даже не продолжает текущую программу; он возвращает управление вызывающей программе, будто бы все прекрасно, в то время как все далеко не прекрасно.
Этот контрпример дает хороший урок Ada-программистам: почти ни при каких обстоятельствах обработчик when не должен заканчиваться return. Слово "почти" употреблено для полноты картины, поскольку есть особый допустимый случай ложной тревоги (false alarm), достаточно редкий, который мы обсудим чуть позже. Опасно и неприемлемо не уведомлять вызывающую программу о возникшей ошибке. Если невозможно исправить ситуацию и выполнить контракт, то программа должна выработать отказ. Язык Ada позволяет сделать это: предложение exception может заканчиваться инструкцией raise без параметров, повторно выбрасывая исходное исключение, передавая его вызывающей программе. Это и есть подходящий способ завершения выполнения, когда невозможно выполнить свой контракт.
Правило исключений языка Ada
Выполнение любого обработчика исключений должно заканчиваться либо выполнением инструкции raise, либо повторением объемлющего программного блока.
Принципы обработки исключений
Контрпримеры помогли указать дорогу к дисциплинированному использованию исключений. Следующие принципы послужат основой обсуждения.
Принципы дисциплинированной обработки исключений
Есть только два легитимных отклика на исключение, возникшее при выполнении программы:

  1. Повторение (Retrying) - попытка изменить условия, приведшие к исключению, и выполнить программу повторно, начиная все сначала.
  2. Отказ (Failure) - известный также как "организованная паника" (organized panic): чистка стека и других ресурсов, завершение вызова и отчет об отказе перед вызывающей программой.

В дополнение, некоторые сигналы операционной системы (случай (3) в классификации исключений) в редких случаях являются откликом на "ложную тревогу". Определив, что исключение безвредно, можно возобновить выполнение в точке прерывания.
Давайте начнем рассмотрение с третьего случая - ложной тревоги, обработка которого соответствует основному механизму C-Unix. Вот пример. Некоторые оконные системы будут вызывать исключения, если пользователь перестраивает размеры окна во время выполнения процесса в этом окне. Предположим, что процесс не выполняет никакого вывода в это окно, тогда исключение будет безвредным, и можно возобновить выполнение процесса в прерванной точке. Но даже в этом случае есть лучшие пути, такие как полная блокировка сигналов на время выполнения процесса, чтобы исключение вообще не встретилось. Именно так мы будем поступать с ложными тревогами в механизме, рассматриваемом в следующем разделе.
Ложные тревоги возможны лишь для одного вида сигналов операционной системы - благоприятных сигналов, но нельзя игнорировать арифметическое переполнение или невозможность выделения запрашиваемой память. Исключения всех других категорий также указывают на трудности, не допускающие игнорирования. Было бы абсурдно, например, запускать программу при ложном предусловии.
Повторение - более обнадеживающая стратегия: мы потерпели поражение в битве, но не проиграли войну. Хотя наш первоначальный план выполнения контракта потерпел неудачу, мы можем постараться удовлетворить клиента, применив другую тактику. Если она будет успешной, то исключение не оказывает никакого влияния на клиента. После одной или нескольких попыток, приведших к неудаче, в очередной попытке нам, возможно, удастся полностью выполнить контракт ("Миссия завершена, сэр. Обычные, небольшие проблемы, сэр. Теперь все хорошо, сэр").
Что значит "другая тактика", испытываемая при следующей попытке? Это может быть другой алгоритм; или тот же алгоритм, выполняемый после некоторых произведенных изменений в начальном состоянии (атрибуты, локальные переменные). В некоторых случаях это может быть просто повторный запуск той же программы в надежде, что изменились внешние условия - освободились временно занятые устройства, линии связи и так далее.
При отказе приходится признавать не только поражение в битве, но и невозможность выиграть войну. Мы сдаемся, но прежде следует выполнить два условия, объясняющие использование термина "организованная паника", как более точного синонима понятия "отказ":

  • Обеспечить появление исключения у вызывающей программы. В этом и состоит аспект "паники" - программа отказывается жить в соответствии с ее контрактом.
  • Восстановить согласованное состояние выполнения - "организованный" аспект.

Что является согласованным состоянием? Корректность класса позволяет дать ответ: состояние, удовлетворяющее инварианту. Мы уже говорили, что программа во время ее выполнения может нарушать инвариант, восстанавливая его в конце работы. Если возникло исключение, то инвариант может быть нарушен. Программа должна восстановить его до возвращения управления вызывающей программе.
Цепочка вызовов
Обсуждая механизм обработки исключений, полезно иметь ясную картину последовательности вызовов, приведших в итоге к исключению. Это понятие уже появлялось при рассмотрении механизма языка Ada.
Пусть r0 будет корневой процедурой некоторой системы (в Ada это программа main). В каждый момент выполнения есть текущая программа, вызванная последней и ставшая причиной исключения. Пройдем по цепочке в обратном порядке, начиная с текущей программы, от вызываемой к вызывающей программе. Реверсная цепочка (r0, последняя вызванная r0 программа r1, последняя вызванная r1 программа r2 и так далее до текущей программы) называется цепочкой вызовов.
Если возникает исключение, то для его обработки, возможно, придется подняться по цепочке, пока не будет достигнута программа, способная справиться с исправлением ситуации. Этот процесс заканчивается, когда достигнута программа r0 и не найден нужный обработчик исключения.
Механизм исключений
Из предшествующего анализа следует механизм исключений, наилучшим образом соответствующий ОО-подходу и идеям Проектирования по Контракту.
Для обеспечения основных свойств введем в язык два новых ключевых слова. Для случаев, в которых необходим точно отрегулированный механизм, будет доступен библиотечный класс EXCEPTIONS.
Спаси и Повтори (Rescue и Retry)
Прежде всего, в тексте программы должна быть возможность указания действий, выполняемых при возникновении исключения. Для этой цели и вводится новое ключевое слово rescue, задающее предложение с описанием действий, предпринимаемых для восстановления ситуации. Поскольку предложение rescue описывает действия, предпринимаемые при нарушении контракта, то разумно поместить его в конце программы после всех других предложений:
routine is
require
precondition
local
... Объявление локальных сущностей ...
do
body
ensure
postcondition
rescue
rescue_clause
end

Предложение rescue_clause является последовательностью инструкций. При возникновении исключения в теле программы вычисление прерывается, и управление передается предложению rescue. Хотя есть только одно такое предложение на программу, но в нем можно проанализировать причину исключения и нужным образом реагировать на различные события.
Другой новой конструкцией является инструкция retry, записываемая просто как retry. Эта инструкция может появляться только в предложении rescue. Ее выполнение состоит в том, что она повторно запускает тело программы с самого начала. Инициализация, конечно, не повторяется.
Эти конструкции являются прямой реализацией принципа Дисциплинированной Обработки Исключений. Инструкция retry обеспечивает механизм повторения; предложение rescue, не заканчивающееся retry приводит к отказу.
Как отказаться сразу
Последнее высказывание достойно возведения в ранг принципа.
Принцип отказа
Завершение выполнения предложения rescue, не включающее инструкции retry, приводит к тому, что вызов программы завершается отказом.
Так что, если и были вопросы, как на практике возникает отказ (ситуация (4) в классификации исключений), то это делается именно так, - при завершении предложения rescue.
В качестве специального случая рассмотрим программу, не имеющую предложения rescue. На практике именно этот случай характерен для огромного большинства программ. В разрабатываемом подходе к обработке исключений лишь избранные из поставляемых программ должны иметь такое предложение. Игнорируя объявления и другие части программы, можно полагать, что программа без предложения rescue имеет вид:
routine is
do
body
end

Тогда, приняв, как временное соглашение, что отсутствие предложения rescue эквивалентно существованию пустого предложения rescue, наша программа эквивалента программе:
routine is
do
body
rescue
-- Здесь ничего (пустой список инструкций)
end

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


Рассмотрение отсутствующего предложения rescue, как присутствующего пустого предложения, является подходящей аппроксимацией на данном этапе рассмотрения. Но нам придется слегка подправить это правило, когда начнем рассматривать эффект исключений на инвариант класса.

Таблица истории исключений
Если в программе произошел отказ, то ли из-за отсутствия предложения rescue, то ли потому, что это предложение закончилось без retry, она прервет выполнение вызывающей программы, вызвав в ней исключение типа (4) - отказ в вызываемой программе. Вызывающая программа столкнется с теми же самыми двумя возможностями: либо в ней есть предложение rescue, способное исправить ситуацию, либо она выработает отказ и передаст управление вверх по цепочке вызовов. Если на всем пути не найдется программы, способной справиться с исключением, то выполнение всей системы закончится отказом. В этом случае окружение должно сформировать и вывести ясную картину произошедшего - таблицу истории исключения. Вот пример такой таблицы:


Таблица 12.1. Пример таблицы истории исключений

Объект

Класс

Программа

Природа исключения

Эффект

O4

Z_Function

split (from E_FUNCTION)

Feature interpolate: Вызывалаcь ссылкой void

Повторение

O3
O2
O2

INTERVAL
EQUATION
EQUATION

integrate
solve (from GENERAL_EQUATION)
filter

interval_big_enough: Нарушено предусловие
Отказ программы
Отказ программы

Отказ
Отказ
Повторение

O2
O1(root)

MATH
INTERFACE

new_matrix (from BASIC_MATH)
make

enough_memory: Check Нарушение
Отказ программы

Отказ
Отказ

Эта таблица содержит историю не только тех исключений, которые привели, в конечном счете, к отказу системы, но и исключений, эффект которых был преодолен в результате выполнения rescue - retry. Число исключений в таблице может быть ограничено, например, числом 100 по умолчанию. Порядок в таблице сверху вниз является обратным порядку, в котором вызываются программы. Корневая процедура создания записана в последней строке таблицы.
Столбец Программа идентифицирует для каждого исключения программу, чей вызов был прерван исключением. Столбец Объект идентифицирует цель этого вызова; используемые здесь имена O1 и так далее, но в реальной трассировке они будут внутренними идентификаторами, позволяющие определить, являются ли объекты совпадающими. Столбец Класс указывает класс, генерирующий объект.
Столбец Природа Исключения указывает, что случилось. Здесь, как показано во второй сверху строке таблицы, могут использоваться метки утверждений, например, interval_big_enough, что позволяет точно идентифицировать нарушаемое предложение в программе.
Последний столбец указывает, как обрабатывалось исключение, то ли используя Повторение, то ли Отказ. Таблица состоит из последовательности секций, отделяемых толстой линией. Каждая секция, за исключением последней, приводила к Повторению, что указывает на восстановление ситуации. Понятно, что между двумя вызовами, отделенными толстыми линиями, может быть произвольное число вызовов.
Игнорируя такие промежуточные вызовы, - успешные и потому неинтересные для цели нашего обсуждения - здесь приведена цепочка вызовов и возвратов, соответствующая выше приведенной истории исключений. Для реконструкции действий следует следовать по стрелкам, обходя их против часовой стрелки, начиная от программы make, изображенной слева вверху.
Примеры обработки исключений
Теперь, когда у нас есть базисный механизм, давайте посмотрим, как он применяется в общих ситуациях.
Поломки при вводе
Предположим, что в интерактивной системе необходимо выдать подсказку пользователю, от которого требуется ввести целое. Пусть только одна процедура занимается вводом целых - read_one_integer, которая результат ввода присваивает атрибуту last_integer_read. Эта процедура работает неустойчиво, - если на ее входе будет нечто, отличное от целого, она может привести к отказу, выбрасывая исключение. Конечно, вы не хотите, чтобы это событие приводило к отказу всей системы. Но поскольку вы не управляете программой ввода, то следует ее использовать и организовать восстановление ситуации, при возникновении исключений. Вот возможная схема:
get_integer is
-- Получить целое от пользователя и сделать его доступным в
-- last_integer_read.
-- Если ввод некорректен, запросить повторения, столько раз,
-- сколько необходимо.
do
print ("Пожалуйста, введите целое: ")
read_one_integer
rescue
retry
end

Эта версия программы иллюстрирует стратегию повторения.
Очевидный недостаток - пользователь упорно вводит ошибочное значение, программа упорно запрашивает значение. Это не очень хорошее решение. Можно ввести верхнюю границу, скажем 5, числа попыток. Вот пересмотренная версия:
Maximum_attempts: INTEGER is 5
-- Число попыток, допустимых при вводе целого.
get_integer is
-- Попытка чтения целого, делая максимум Maximum_attempts попыток.
-- Установить значение integer_was_read в true или false
-- в зависимости от успеха чтения.
-- При успехе сделать целое доступным в last_integer_read.
local
attempts: INTEGER
do
if attempts < Maximum_attempts then
print ("Пожалуйста, введите целое: ")
read_one_integer
integer_was_read := True
else
integer_was_read := False
end
rescue
attempts := attempts + 1
retry
end

Предполагается, что включающий класс имеет булев атрибут integer_was_read.
Вызывающая программа должна использовать эту программу следующим образом, пытаясь введенное целое присвоить сущности n:
get_integer
if integer_was_read then
n := last_integer_read
else
"Иметь дело со случаем, в котором невозможно получить целое"
end

Восстановление при исключениях, сгенерированных операционной системой
Среди событий, включающих исключения, есть сигналы, посылаемые операционной системой, некоторые из которых являются следствием аппаратных прерываний. Примеры: арифметическое переполнение сверху и снизу, невозможные операции ввода-вывода, запрещенные команды, обращение к недоступной памяти, прерывания от пользователя (например, нажата клавиша break).
Теоретически можно рассматривать такие условия, как нарушение утверждений. Если a+b приводит к переполнению, то это означает, что вызов не удовлетворяет неявному предусловию функции + для целых или вещественных чисел, устанавливающее, что сумма двух чисел должна быть представима в компьютере. Подобное неявное предусловие задается при создании новых объектов (создание копии) - памяти должно быть достаточно. Отказы встречаются из-за того, что окружение - файлы, устройства, пользователи - не отвечают условиям применимости. Но в таких случаях непрактично или невозможно задавать утверждения, допуская их независимую проверку. Единственное решение - пытаться выполнить операцию, и, если аппаратура или операционная система выдает сигнал о ненормальном состоянии, рассматривать его как исключение.
Рассмотрим проблему написания функции quasi_inverse, возвращающей для каждого вещественного x обратную величину 1/x или 0, если x слишком мало.
Подобные задачи по существу нельзя реализовать, не используя механизм исключений. Единственный практичный способ узнать, можно ли для данного x получить обратную величину, это выполнить деление. Но деление может спровоцировать переполнение, и если нет механизма управления исключениями, то программа завершится отказом, и будет слишком поздно возвращать 0 в качестве результата.


На некоторых платформах можно написать функцию invertible, такую что invertible(x) равна true, если и только если обратная величина может быть вычислена. Тогда можно написать и quasi_inverse. Но это решение не будет переносимым, и может приводить к потере производительности при интенсивном использовании этой функции.

Механизм rescue-retry позволяет просто решить эту проблему, по крайней мере, на платформе, включающей сигнал при арифметическом переполнении:
quasi_inverse (x: REAL): REAL is
-- 1/x, если возможно, иначе 0
local
division_tried: BOOLEAN
do
if not division_tried then
Result := 1/x
end
rescue
division_tried := True
retry
end

Правила инициализации устанавливают значение false для division_tried в начале каждого вызова. В теле не нужно предложение else, поскольку инициализация установит Result равным 0.
Повторение программы, толерантной к неисправностям
Предположим, вы написали текстовый редактор, и к вашему стыду нет уверенности, что он полностью свободен от жучков. Но вам хочется передать эту версию некоторым пользователям для получения обратной связи. Нашлись смельчаки, готовые принять систему с оставшимися ошибками, понимая, что могут возникать ситуации, когда их запросы не будут выполнены. Но они не будут тестировать ваш редактор на серьезных текстах, (а именно это вам и требуется), если будут бояться, что отказы могут привести к катастрофе, например грубый выход с потерей текста, над которым шла работа последние полчаса. Используя механизм повторения, можно обеспечить защиту от такого поведения.
Предположим, что редактор, как это обычно бывает для подобных систем, содержит основной цикл, выполняющий команды редактора:
from ... until exit loop
execute_one_command
end

где тело программы execute_one_command имеет вид:
"Декодировать запрос пользователя"
"Выполнить команду, реализующую запрос"

Инструкция "Выполнить ..." выбирает нужную программу (например, удалить строку, заменить слово и так далее). Мы увидим в последующих лекциях, как техника наследования и динамическое связывание дает простые, элегантные структуры для подобных ветвящихся решений.
Будем исходить из того, что не все эти программы являются безопасными. Некоторые из них могут отказать в непредсказуемое время. Вы можете обеспечить примитивную, но эффективную защиту против таких событий, написав программу следующим образом:
execute_one_command is
-- Получить запрос от пользователя и, если возможно,
-- выполнить соответствующую команду.
do
"Декодировать запрос пользователя"
"Выполнить подходящую команду в ответ на запрос"
rescue
message ("Извините, эта команда отказала")
message ("Пожалуйста, попробуйте использовать другую команду")
message ("Пожалуйста, сообщите об отказе автору")
"Команды, латающие состояние редактора"
retry
end

Эта схема предполагает на практике, что поддерживаемые запросы пользователя включают: "сохранить текущее состояние работы", "завершить работу". Оба последних запроса должны работать корректно. Пользователь, получивший сообщение "Извините...", несомненно, захочет сохранить работу и выйти как можно скорее. Некоторые из программ, реализующих команды редактора, могут иметь собственные предложения rescue, хотя и приводящие к отказу, но предварительно выдающие более информативные сообщения.
N-версионное программирование
Другим примером повторения программы, толерантной к неисправностям, является реализация 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. После чего могут встретиться два случая:

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

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

Задача предложения rescue

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

  1. Для каждой экспортируемой программы r и любого множества правильных аргументов xr
  • {prer (xr) and INV} Bodyr {postr (xr) and INV}

            
Для простоты позвольте в дальнейшем рассмотрении игнорировать аргументы xr.
Пусть Rescuer обозначает ту часть предложения rescue, в которой игнорируются все ветви, ведущие к retry, другими словами в этой части сохраняются все ветви, доходящие до конца предложения rescue. Правило (2) задает спецификацию для программ тела - Bodyr. Можно ли получить такую же спецификацию для Rescuer? Она должна иметь вид:
{ ? } Rescuer { ? }

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

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика