В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 35

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 35)

реагировать на исключение, и принят практически во всех ЯП принцип

динамической ловушки.

Обратите внимание, объявляются исключения статически, подобно

переменным и процедурам, а реакции на них выбираются динамически из

статически определенного множества возможных реакций.

Если разрешить вводить новые имена исключений динамически, то следовало

бы создавать динамически и реакции на них, т.е. динамически создавать

программу. Такого рода возможности противоречат концепции статического

контроля и в современных языках индустриального программирования практически

не встречаются.

Вообще в современных ЯП поведение исполнителя в режиме обработки

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

такой житейской возможности, как сообщить "начальству" и ждать распоряжений

"на месте происшествия". Или позвонить сразу и в милицию, и в скорую помощь,

и в пожарную охрану, одновременно принимая собственные меры. Конечно, всякое

поведение можно моделировать, но, например, несколько исключений в одном

месте возникнуть не могут.

8.3.3. Реакция на исключение - принципы пластыря и катапульты.

Принятая в ЯП стратегия обработки исключений прямо связана со взглядом

на сущность исключений. Этот взгляд, в свою очередь, зависит от важнейших

требований, определивших авторскую позицию при создании ЯП. Хотя в конечном

итоге различия поведения могут показаться не такими уж значительными,

рассмотреть их обоснование и интересно, и поучительно. Выберем для

определенности два ЯП: ПЛ/1 и Аду. Скажем заранее, что различия касаются

лишь продолжения работы после реакции на исключение.

Принцип пластыря. Сначала о ПЛ/1. Несколько упрощая, можно сказать, что

один из основных принципов конструирования языка ПЛ/1 - "предпочитать такие

истолкования конструкций, которые позволяют оправдать их дальнейшее

исполнение". В соответствии с этим принципом введены многочисленные правила

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

и т.п.

В согласии с этим принципом исключение трактуется как относительно

редкое, но в целом естественное для выполняемого конструкта событие. При его

обработке следует направить усилия на скорейшее возобновление прерванного

процесса. Эти усилия можно наглядно представить себе как наложение пластыря

на "рану". Естественная модель поведения - прервать исполняемый процесс,

вызвать "врачебную бригаду", после окончания "лечения" продолжить прерванный

процесс. Обратите внимание на три составляющих поведения - прервать, вызвать

(это значит, понять, кого вызвать - врачебная бригада подбирается

динамически) и продолжить.

Подобный взгляд полезен, например, при нехватке памяти - нужно вызвать

подпрограмму сборки мусора или подпрограмму динамического выделения памяти,

а затем попытаться продолжить работу. Описанное отношение к сущности

исключения можно назвать принципом пластыря.

Однако где гарантии, что "заклеенный" процесс сможет нормально

работать? Если исключение связано с окончанием файла или нарушением

диапазона, то бессмысленно продолжать работу прерванного процесса. В ПЛ/1 в

таких случаях в реакции на исключение (после "лечения", если оно требуется)

применяют передачу управления туда, откуда признано разумным продолжать

работу. Например

ON ENDFILE GOTO M1;

По многим причинам это далеко не лучшее решение. Одна из основных

причин в том, что динамическая структура программы оказывается слабо

связанной с ее статической структурой. Чтобы разобраться в программе,

приходится "прокручивать" каждый оператор. Короче говоря, решение с

передачей управления в общем случае затрудняет чтение и отладку программ. По

"неструктурированности" это решение можно сравнить с выходом из подпрограммы

не по возврату, а по передаче управления. Что при этом происходит с

динамической цепочкой вызовов? Остается только гадать или определять,

руководствуясь "тонкими" правилами!

Итак, будем считать обоснованным, что решение с передачей управления

противоречит концепции "структурного программирования". В Аде стараются

обойтись без goto, тем более что таким способом "далеко не уйдешь" - в этом

ЯП самая вложенная последовательность операторов, окружающая объявление

метки, должна окружать и оператор перехода на эту метку. А без передачи

управления принцип пластыря не позволяет адекватно обрабатывать многие виды

исключений.

Упражнение. Приведите соответствующие примеры.

Принцип катапульты. Одно из ключевых требований к языку Ада -

способствовать надежному программированию. Другими словами, следует

стремиться к минимуму отказов из-за ошибок в программе и в данных. Когда же

отказ неизбежен, то следует обеспечить по меньшей мере осмысленную

диагностику.

Требование надежности оправдывает трактовку исключения как

свидетельства полной непригодности "аварийного процесса" (процесса, где

возникло исключение) к нормальной работе в создавшихся условиях. Стремясь к

минимуму отказов, следует не "лечить" аварийный процесс, а нацелить

обработку исключения на локализацию последствий "аварии", на создание

возможности продолжать работу тех (связанных с аварийным) процессов, которых

авария пока не коснулась.

Саму обработку исключения в "аварийном" процессе обычно разумно

рассматривать скорее не как "лечение", а как "посмертную выдачу" - попытку

сохранить как можно больше сведений для анализа ситуации на уровне иерархии,

принимающем решения о последующих действиях.

Именно такой принцип действует в Аде (ведь надежность - одна из

основных целей этого ЯП), а также в ЯП Эль-76 для машин серии Эльбрус.

При такой цели естественная стратегия - последовательно признавать

аварийными вложенные процессы (начиная с самого внутреннего) до тех пор,

пока среди них не найдется процесс, в котором приготовлена реакция на

возникшее исключение. При этом аварийные процессы, в которых нет нужной

реакции, последовательно завершаются аварийным способом

("катапультированием"). Найденная в конечном итоге реакция на исключение

призвана обеспечить нормальное продолжение работы уцелевших процессов (и,

возможно, выдачу сообщения об ошибке).

Итак, никакого возврата к аварийному процессу при такой стратегии нет,

а значит, нет и опасности вызвать "лавину" исключений и сообщений об

авариях. Если ведущий процесс сочтет возможным, он может снова запустить (в

новых условиях) и бывший аварийный процесс. Но решение об этом не встроено в

семантику ЯП, а программируется на уровне иерархии, высшем по отношению к

аварийному процессу.

Назовем описанный принцип обработки исключений принципом катапульты.

Название связано с тем, что исключение заставляет управление немедленно

покинуть признанный аварийным процесс, приняв меры к спасению самой ценной

информации (вполне аналогично тому, как катапультируется с аварийного

самолета летчик, спасая самое ценное - человеческую жизнь).

Именно этот принцип поведения исполнителя в исключительных ситуациях

воплощен в Аде (как целиком отвечающий требованиям к этому ЯП и, в

частности, способствующий надежному и структурному программированию). Пример

в п.8.3.1.а показывает, как можно ликвидировать аварию и продолжить работу

(после реакции на исключение управление покидает блок B).

8.3.4. Ловушка исключений

Итак, в зависимости от ЯП реакция на исключение может быть и

"пластырем", и "катапультой". Осталось объяснить, как она устроена.

В общем случае тела подпрограмм, тела пакетов, тела задач, а также

блоки содержат в конце обычной последовательности операторов еще часть,

отделенную ключевым словом exception. Это и есть ловушка исключений. Она

устроена аналогично оператору выбора, но вместо значений перечисляемого типа

после ключевого слова when фигурируют имена исключений.

Например,

begin

... -- последовательность операторов

exception -- ловушка исключений

when плохо_обусловленная | численная ошибка =>

PUT("матрица плохо обусловлена");

when others =>

PUT("фатальная ошибка");

raise ошибка;

end ;

Альтернатива others, как обычно, выбирается в том случае, когда не

выбраны остальные. В нашем примере при возникновении исключения

плохо_обусловленная или численная_ошибка (первое - объявляемое, второе -

предопределенное) печатается "плохо обусловленная матрица" и обработка

исключения завершается (затем продолжает нормально работать динамический

объемлющий процесс). Любые другие исключения будут пойманы альтернативой

others, будет напечатано "фатальная ошибка" и возникнет новое исключение

"ошибка" как результат работы оператора исключения (raise).

Это исключение будет распространяться в динамически объемлющих

процессах, пока не попадет в ловушку (для предопределенных исключений

ловушки предусмотрены в предопределенном пакете "система"). Если бы второй

альтернативы не было, то любое исключение, отличное от двух указанных в

первой альтернативе нашей ловушки, распространялось бы по динамически

объемлющим процессам до "своей" ловушки.

8.4. Дополнительные особенности обработки исключений

Исключения в объявлениях. Когда исключение возникает в объявлениях

некоторого конструкта, то оно немедленно распространяется на динамически

объемлющие конструкты. Собственная ловушка конструкта рассчитана только на

исключения, возникшие среди операторов конструкта. Это правильно, так как в

ловушке могут использоваться объекты, которые из-за "недообработки"

объявлений (ведь в них возникла авария) окажутся еще несуществующими.

Приведенный выше пример показывает, что есть и еше одна причина - можно

попасть в бесконечный цикл, если при возникновении исключения "ошибка"

искать реакцию в той же ловушке. Напомним, что саму ловушку естественно

считать объявлением - а именно объявлением "тел" исключений.

Исключения в асинхронных процессах. Интересно рассмотреть особенности

распространения исключений на взаимодействующие задачи. У тела задачи нет

динамически объемлющего процесса - соответствующий телу задачи процесс

работает асинхронно, с ним могут быть динамически связаны посредством

рандеву много других "равноправных" процессов-партнеров. С другой стороны,

каждый асинхронный процесс запускается при обработке некоторого

фиксированного объявления в определенном "родительском" конструкте.

Поэтому, когда исключение возникает среди объявлений задачи, то эта

задача аварийно завершается и на месте запустившего ее объявления (задачи) в

родительском процессе возникает предопределенное исключение

ошибка_взаимодействия. Другими словами, о возникшей чрезвычайной ситуации в

задаче немедленно "узнает" запускающий ее процесс (например для того, чтобы

можно было заменить не запущенную задачу). Заменить можно потому, что

запускаемая задача еще наверняка не успела вступить во взаимодействие со

своими асинхронными партнерами (почему?), и их можно пока не предупреждать

об аварии. Не успела она и запустить дочерние процессы-потомки (потому что

они считаются запущенными только после нормального завершения обработки

раздела объявлений в родительском процессе).

С другой стороны, если потенциальный клиент так и не запущенной

(аварийной) задачи попытается обратиться к ее входу, то в этом клиенте на

месте вызова входа возникнет исключение ошибка_взаимодействия (такое

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

оказывается не работающим). Так что исключение в случае аварии в одном из

асинхронных процессов распространяется не только "линейно" вверх по цепочке

от потомков к родителям, но и "веером" ко всем клиентам.

Когда же исключение возникает не в объявлениях, а в теле задачи и в

своем распроcтранении доходит до самой внешней в этом теле ловушки, то

Характеристики

Список файлов книги