Программист-прагматик. Путь от подмастерья к мастеру

      Выражая область значений функции извлечения квадратного корня в предусловии подпрограммы sqrt, вы перекладываете ответственность за правильность на вызывающую программу, которой она принадлежит. Затем вы можете спокойно продолжать разработку подпрограммы sqrt, зная, что ее входные параметры не выйдут за пределы соответствующей области.
 
      Если ваш алгоритм извлечения квадратного корня не работает (или выходит за пределы погрешности), вы получите сообщение об ошибке и трассировку стека, указывающую на цепочку вызовов.
      Если вы передаете sqrt отрицательный параметр, рабочая среда Eiffel выводит на печать ошибку "sqrt_argjnust_be_positive" (аргумент функции sqrt должен быть положительным) наряду с трассировкой стека. Этот вариант реализован лучше, чем его аналогия в языках типа Java, С, и С++, где при передаче отрицательного числа в sqrt выдается специальное значение NaN (Not a Number – не число). Далее по ходу программы, когда вы попытаетесь произвести со значением NaN некие математические действия, результаты этого будут поистине удивительными.
      Проблему намного проще найти и диагностировать "не сходя с места", при аварийном завершении работы программы.

Другие случаи применения инвариантов

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

Инварианты цикла

      Понимание граничных условий для нетривиального цикла может оказаться проблематичным. Циклы испытывают воздействие "проблемы банана" (я знаю, как записать по буквам слово «банан», но не знаю, в какой момент нужно остановиться), ошибки "постов охраны" (путаница в том, что подсчитывать: сами посты или интервалы между ними) и вездесущей ошибки завышения (занижения) [URL 52].
      В подобных ситуациях инварианты могут быть полезными: инвариант цикла представляет собой оператор возможной цели цикла, но он обобщен таким образом, что также истинен перед тем, как цикл выполняется, и при каждой итерации, осуществляемой с помощью цикла. Его можно считать контрактом в миниатюре. Классическим примером является подпрограмма поиска максимального элемента в массиве.
      int m = arr[0]; // пример предполагает, что длина массива > 0
      int i = 1;
      // Инвариант цикла: m = max(arr[0:i-1])
      while (i < arr.length) {
          m = Math.max(m, arr[i]);
          i = i + 1;
      }
      (arr [m:n] – принятое обозначение фрагмента массива, элементы которого имеют индексы от m до n). Инвариант должен быть истинным до начала выполнения цикла, а тело цикла должно гарантировать, что инвариант будет оставаться истинным во время выполнения цикла. Таким образом, нам известно, что инвариант истинен после выполнения цикла, и следовательно наш результат является достоверным. Инварианты цикла могут быть запрограммированы в явном виде (как утверждения); они также полезны при проектировании и документировании.

Семантические инварианты

      Вы можете использовать семантические инварианты для выражения неизменных требований при составлении своего рода "философского контракта".
      Однажды авторы книги написали программу обработки транзакций для дебетовых банковских карт. Главное требование заключалось в том, что пользователь дебетовой карты не должен проводить на своем счете одну и ту же транзакцию. Другими словами, ошибка скорее повлечет за собой отмену обработки транзакции, чем инициирует обработку дублированной транзакции – независимо от характера сбоя в системе.
      Это простое правило, исходящее непосредственно из требований, доказало свою полезность при отсеивании сложных сценариев исправления ошибок и является руководством при детальном проектировании и реализации во многих областях.
      Но убедитесь в том, что вы не смешиваете требования, представляющие собой жесткие, неизменные законы с теми, что являются не более чем политикой, которая может измениться вместе с правящим режимом. Именно поэтому мы используем термин "семантические инварианты" – он должен занимать главенствующее место при определении сути предмета и не подчиняться прихотям политики (для которой предназначаются более динамичные правила ведения бизнеса).
      Если вы обнаруживаете подходящее требование, убедитесь, что оно становится неотъемлемой частью любой создаваемой вами документации – будь то маркированный список в требованиях, которые подписываются в трех экземплярах, или большое объявление на обычной лекционной доске, которое не заметит разве что слепой. Постарайтесь сформулировать его четко и однозначно. Например, в случае с дебетовой картой можно было бы записать:
      ERR IN FAVOR OF THE CONSUMER (ОШИБКА В ПОЛЬЗУ КЛИЕНТА)
      Это и есть четкая, сжатая, однозначная формулировка, которая применима к различным областям системы. Это наш контракт со всеми пользователями системы, наша гарантия ее поведения.

Динамические контракты и агенты

      До сих пор мы говорили о контрактах как о неких фиксированных, раз и навсегда установленных спецификациях. Но в случае с автономными агентами этого быть не должно. Из определения автономных агентов следует, что они могут отвергать запросы, которые не хотят выполнять. Они могут обговаривать условия контракта – "я не могу предоставить то-то и то-то, но если вы дадите мне вот это, тогда я смогу предоставить что-то другое".
      Конечно, любая система, которая полагается на технологию агентов, обладает критической зависимостью от положений контракта, даже если они генерируются динамически.
      Только представьте себе: при достаточном количестве элементов и агентов, которые для достижения конечной цели могут обговаривать свои собственные контракты между собой, можно было бы просто выйти из кризисной ситуации, связанной с производительностью, позволив программам решать проблемы за нас.
      Но если мы не можем использовать контракты «вручную», то мы не сможем использовать их и автоматически. Поэтому в следующий раз, когда вы будете проектировать фрагмент программы, проектируйте и его контракт.

Другие разделы, относящиеся к данной теме:

      • Ортогональность
      • Мертвые программы не лгут
      • Программирование утверждений
      • Балансировка ресурсов
      • Несвязанность и закон Деметера
      • Временное связывание
      • Программирование в расчете на совпадение
      • Программа, которую легко тестировать
      • Команды прагматиков

Вопросы для обсуждения

      • Информация к размышлению: Если принцип ППК является столь мощным, почему бы не применять его более широко? Насколько сложно выйти на контракт? Заставляет ли он вас думать о вещах, которые вы бы в данный момент проигнорировали? Заставляет ли он вас ДУМАТЬ? Это явно небезопасный принцип!

Упражнения

      14. Из чего получается удачный контракт? Можно добавлять любые предусловия и постусловия, но есть ли от них толк? Не могут ли они принести больше вреда, чем пользы? Определите, какими являются контракты в примере ниже и упражнениях 15 и 16: удачными, неудачными, уродливыми, и объясните, почему.
      Рассмотрим вначале пример, написанный на языке Eiffel. Имеется программа для добавления STRING к двунаправленному циклическому списку (следует помнить, что предусловия обозначены require, а постусловия – ensure).
      -- Добавляем элемент в двунаправленный список,
      -- и возвращаем вновь созданный узел (NODE).
      add_tem (item: STRING): NODE is
      require
      item /= Void -- /= означает 'не равно'.
      deferred -- Абстрактный базовый класс
      ensure
      result.next.previous = result -- Проверка связей вновь
      result.previous.next = result -- вновь добавленного узла.
      find_item(item) = result  -- Должен найти его.
      end
      15. Теперь рассмотрим пример на языке Java – нечто подобное примеру, из упражнения 14. Оператор InsertNumber вставляет целое число в упорядоченный список. Предусловия и постусловия обозначены в соответствии с сайтом iContract (см. [URL 17]). (Ответ см. в Приложении В.)
      private int data[];
      /**
      * @post data[index-1] < data[index] &&
      * data[index] == aValue
      */
      public Node insertNumber (final int aValue)
      {
      int index = findPlaceTolnsert(aValue);
      ...
      16. Фрагмент стекового класса на языке Java. Можно ли назвать этот контракт удачным? (Ответ см. в Приложении В.)
 
      /**
      * @рге anltem != null // Требует реальных данных
      * @post рор() == anltem // Проверяет их наличие
      * // в стеке
      */
      public void рush(final String anltem)
 
      17. В классических примерах использования принципа ППК (см. упражнения 14–16) реализуется абстрактный тип данных – обычно это стек, или очередь. Но немногие действительно создают подобные разновидности низкоуровневых классов.
      В данном упражнении требуется спроектировать интерфейс блендера для коктейлей. Он должен основываться на web-технологии, включаться по сети Интернет и использовать технологию CORBA, но в данный момент необходим лишь интерфейс управления. Блендер имеет десять скоростей (0 означает отключение); он не должен работать вхолостую а его скорость может единовременно изменяться на одну ступень (т. е. с 0 до 1, или с 1 до 2, но не сразу с 0 до 2).
      Методы указаны ниже. Добавьте соответствующие предусловия и постусловия, а также инвариант. (Ответ см. в Приложении В.)
      int getSpeed()
      void setSpeed(int x)
      booolean isFull()
      void fill()
      void empty()
 
      18. Сколько чисел содержится в ряду 0, 5, 10, 15…, 100? (Ответ см. в Приложении В.)

22
Мертвые программы не лгут

      Приходилось ли вам замечать, что иногда, еще до того как вы осознаете проблему, ее признаки обнаруживают посторонние люди? То же самое применимо и к программам других разработчиков. Если в одной из наших программ что-то начинает идти не так, как надо, в ряде случаев первой это «заметит» библиотечная подпрограмма. Возможно, паразитный указатель заставил нас записать в дескриптор файла какие-то бессмысленные символы. При следующем обращении к read это будет обнаружено. Возможно, что переполнение буфера привело к уничтожению счетчика, который мы собирались использовать для определения объема назначаемой памяти. Возможно, причиной сбоя окажется malloc. Логическая ошибка в одном из нескольких миллионов операторов, находящихся в тексте перед оператором выбора, означает, что его селектор больше не примет значение 1, 2 или 3. Мы берем случай default (который является одной из причин того, почему любой оператор выбора должен иметь значение по умолчанию), мы хотим знать, в какой момент произошло невозможное).
      Легко поддаться умонастроению "этого не может быть, потому что не может быть никогда". Большинство из нас создавало программы, которые не проверяют, успешно ли завершилась операция закрытия файла и правильно ли записан оператор трассировки. И все сводилось к одному (к тому, что мы и так знали) – рассматриваемая программа не откажет, если будет работать в нормальных условиях. Но мы пишем программы с осторожностью. Мы ищем инородные указатели в других частях нашей программы, очищая стек. Мы выясняем, какие версии библиотек совместного пользования загружались в действительности.
      Все ошибки дают вам информацию. Вы могли внушить себе, что ошибка произойти не может, и проигнорировать эту информацию. В отличие от вас, прагматики говорят себе, что если ошибка имеет место, то произошло что-то очень скверное.
 

      Подсказка 32: Пусть аварийное завершение работы программы произойдет как можно раньше

 

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

      Одним из преимуществ скорейшего обнаружения проблем является то, что аварийное завершение происходит как можно раньше. И во многих случаях такое завершение программы – это лучший выход из положения. Альтернативой может быть продолжение работы, запись поврежденных данных в жизненно важную базу данных или команда стиральной машине на проведение двадцатого по счету цикла отжима.
      Эта философия воплощена в языке и библиотеках Java. Когда в системе выполнения случается что-то непредвиденное, происходит возбуждение исключения RuntimeException. Если это исключение не перехвачено, оно будет двигаться на верхний уровень программы и заставит ее прекратить работу, отобразив трассировку стека.
      То же самое можно реализовать и на других языках программирования. Если механизм исключения отсутствует или библиотеки не возбуждают исключения, то убедитесь в том, что можете обрабатывать ошибки самостоятельно. В языке С для этого весьма полезны макрокоманды:
      #define CHECK(LINE, EXPECTED) \
       {int rc = LINE; \
        if (rc!= EXPECTED) \
         ut_abort(_FILE_, _LINE_, #LINE, rc, EXPECTED); }
      void ut_abort(char *file, int In, char *line, int rc, int exp) {
          fprintf(stderr, "%s line %d\n'%s': expected %d, got %d\n", file, In, line, exp, rc);
      exit(1);
      }
 
      Тогда вы можете инкапсулировать вызовы, которые никогда подведут, с помощью строки:
      CHECK(stat("/tmp", &stat_buff), 0);
 
      Если бы это не удалось, то вы бы получили сообщение, записанное в stderr:
      source.c line 19
      "stat("/tmp", &stat_buff)' : expected 0, got -1
      Ясно, что в ряде случаев выход из выполняющейся программы просто не уместен. Возможно, вы претендуете на ресурсы, которые не освобождены, или же вам необходимо записать сообщения в журнал, завершить открытые транзакции или взаимодействовать с другими процессами. Здесь будут полезны методики, обсуждаемые в разделе "Случаи, когда необходимо использовать исключения". Однако основной принцип остается тем же – если ваша программа обнаруживает, что произошло событие, которое считалось невозможным, программа теряет жизнеспособность. Начиная с этого момента, все действия, совершаемые программой, попадают под подозрение, так что выполнение программы необходимо прервать как можно быстрее. В большинстве случаев мертвая программа приносит намного меньше вреда, чем испорченная.

Другие разделы, относящиеся к данной теме:

      • Проектирование по контракту
      • Когда использовать исключения

23
Программирование утверждений

      В самобичевании есть своего рода сладострастие. И когда мы сами себя виним, мы чувствуем, что никто другой не вправе более винить нас.
Оскар Уайльд, Портрет Дориана Грея

      В самом начале своей профессиональной карьеры каждый программист обязан выучить некую мантру. Она представляет собой фундаментальную основу компьютерных вычислений, основное вероучение, которое мы учимся применять к требованиям, конструкциям, самим программам, комментариям – словом, всему, что мы делаем. Она звучит так:
      "Этого никогда не случится…"
      И далее: "Через 30 лет эта программа использоваться не будет, так что для обозначения года хватит и двух разрядов". "Нужна ли интернационализация, если это приложение не будет использоваться за рубежом?" "Счетчик не может принимать отрицательное значение". "Этот оператор printf не дает сбоев".
      Не стоит заниматься подобного рода самообманом, особенно при написании программ.
 

      Подсказка 33: Если что-либо не может произойти, воспользуйтесь утверждениями, которые гарантируют, что это не произойдет вовсе

 
      Всякий раз, когда вы начинаете думать "Ну конечно, такого просто не может произойти", проверяйте это высказывание с помощью программы. Самый простой способ осуществить это – использовать утверждения. В большинстве реализаций языков С и С++ имеется некоторая разновидность макроса assert или _assert, который осуществляет проверку логического условия. Эти макрокоманды могут представлять огромную ценность. Если указатель, передаваемый к вашей процедуре, ни в коем случае не должен принимать значение NULL, то проверьте выполнение этого условия:
      void writeString(char *string) {
         assert(string != NULL);
      ...
      Утверждения представляют собой весьма полезное средство проверки работы алгоритма. Например, вы написали умный алгоритм сортировки. Проверьте, работает ли он:
      For (int i=0; i<num_entries-1; i++) {
         assert(sorted[i] <= sorted[i+1]);
      }
      Конечно, условие, переданное утверждению, не должно оказывать побочного воздействия (см. врезку "Утверждения и побочные эффекты"). Необходимо также помнить, что утверждения могут отключаться во время компиляции – не помещайте в макрос assert программу, которая должна быть выполнена. Утверждения не должны использоваться вместо реальной обработки ошибок. Они лишь осуществляют проверку того, что никогда не должно произойти; вы же не хотите писать программу, подобную приведенной ниже:
      printf("Enter 'Y' or 'N': ");
      ch = getchar()
      assert((ch=='Y')||(ch=='N')); /* дурной тон! */
      И поскольку имеющаяся макрокоманда assert вызывает exit, если утверждение ложно, нет никаких оснований для того, чтобы этого не могли сделать создаваемые вами версии программы. Если вам приходится освобождать ресурсы, сделайте так, чтобы невыполнение утверждения возбуждало исключение или осуществляло переход longjump к точке выхода, или же вызывало обработчик ошибки. Убедитесь в том, что программа, которая исполняется в течение миллисекунд, не использует информацию, которая привела к невыполнению утверждений.

Не отключайте утверждения

      Существует расхожее недопонимание утверждений, которое провозгласили те, кто разрабатывает компиляторы и языковые среды. Оно формулируется примерно так:

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

      В этом высказывании имеется два явно неправильных предположения. Первое – авторы высказывания полагают, что при тестировании обнаруживаются все ошибки. В действительности маловероятно, что процедура тестирования любой сложной программы всегда будет происходить по единому сценарию, даже при минимальном проценте перестановок в тексте программы (см. "Безжалостное тестирование"). Второе – эти оптимисты забывают, что ваша программа выполняется в опасном мире. Весьма вероятно, что во время тестирования крысы не будут прогрызать кабели, никто не будет забивать память, запуская игрушку, а файлы журналов не переполнят жесткий диск. Все это может происходить, если ваша программа выполняется в реальных условиях. Ваш первый оборонительный рубеж – проверка наличия любой вероятной ошибки, а второй – использование утверждений для обнаружения тех ошибок, которые прошли первый рубеж.
      Отключение утверждений при доставке программы заказчику сродни хождению по канату без страховочной сетки на том основании, что когда-то вы уже так делали. Сумма страховки велика, но получить ее в случае падения довольно сложно.
      Даже при наличии некоторых проблем с производительностью, отключите только те утверждения, которые действительно оказывают серьезное воздействие. Пример с программой сортировки, представленный выше, может быть самой важной частью вашего приложения и, наверное, должен работать быстро. Добавление процедуры проверки означает новое считывание данных, что может быть неприемлемо. Сделайте эту конкретную процедуру проверки необязательной , но оставьте в покое все остальные.

Утверждения и побочные эффекты

      Становится как-то неловко, если программа, добавляемая для обнаружения ошибок, в результате создает новые. Это может происходить с утверждениями в том случае, если вычисление условия имеет побочные эффекты. Например, было бы дурным тоном написать на языке Java нечто вроде:
      while (iter.hasMoreElements() {
        Test.ASSERT(iter.nextElement() != null);
        Object obj = iter.nextElement();
      // ...
      }
      Вызов .nextElement() в ASSERT обладает побочным эффектом, заключающимся в перемещении указателя цикла за выбираемый элемент, так что цикл обрабатывает лишь половину элементов совокупности. Лучше было бы записать:
      while (iter.hasMoreElements()) {
      Object obj = iter.nextElement();
      Test.ASSERT(obj != null);
      //…
      }
      Эта проблема являются разновидностью так называемого «Heisen-bug» – процесса отладки, изменяющего поведение отлаживаемой системы (см. [URL 52]).

Другие разделы, относящиеся к данной теме:

      • Отладка
      • Проектирование по контракту
      • Балансировка ресурсов
      • Программирование в расчете на совпадение

Упражнения

      19. Быстрый тест на ощущение реальности. Какие из перечисленных «невозможных» событий могут случаться в реальности? (Ответ см. в Приложении В.)
      1. Месяц, количество дней в котором меньше 28
      2. Stat(".",&sb)== –1 (т. е. невозможно обращение к текущему каталогу)
      3. В языке С++: а = 2; b = 3; if (а + b != 5) exit(1);
      4. Треугольник, сумма величин внутренних углов которого не равна 180°
      5. Минута, состоящая не из 60 секунд
      6. В языке Java: (а + 1) <= а
      20. Разработайте несложный класс Java для проверки утверждений (Ответ см. в Приложении В.)

24
Случаи, в которых используются исключения

      В разделе "Мертвые программы не лгут" высказано предложение считать хорошим тоном проверку всех возможных ошибок, в особенности возникающих неожиданно. Однако на практике это может привести к тому, что программа станет уродливой; нормальная логика вашей программы может сойти на нет из-за ее затуманивания процедурами обработки ошибок, особенно если вы являетесь приверженцем школы программирования, девиз которой звучит так: "В подпрограмме должен иметься один-единственный оператор return" (авторы не являются приверженцами указанной школы). Нам приходилось видеть текст программы, выглядевший следующим образом:
      retcode = OK;
      if (socket.read(name)!=OK) {
        retcode = BAD_READ;
      }
      else
        processName(name);
        if (socket.read(address)!=OK) {
           retcode = BAD READ;
        }
        else {
           processAddress(address);
           if (socket.read(telNo)!= OK) {
              retcode= BAD_READ
         }
          else {
      // etc, etc…
         }
        }
      }
      return retcode;
      Но если язык программирования (no счастливой случайности) поддерживает исключения, то эту программу можно написать намного изящнее:
      retcode = OK;
      try {
        socket.read(name);
        process(name);
        socket.read(address);
        processAddress(address);
        socket.read(telNo);
      // etc, etc…
      }
      catch (lOException e) {
         retcode = BAD_READ;
         Logger.log("Error reading individual;" +e.getMessage());
       }
      return retcode;
      Теперь схема управления отличается ясностью – вся обработка ошибок сосредоточена в одном-единственном месте.

Что является исключительным?

      Одна из проблем, связанных с исключениями, заключается в том, что необходимо знать, когда их можно использовать. Мы полагаем, что не стоит злоупотреблять исключениями для нормального хода выполнения программы; они должны быть зарезервированы для нештатных ситуаций. Предположите, что неперехваченное исключение прекратит работу вашей программы, и спросите себя: "А будет ли эта программа исполняться, если удалить все обработчики исключений?". Если ответ отрицательный, то вполне возможно, что исключения используются в обстоятельствах, их не требующих.
      Например, если ваша программа пытается открыть файл для чтения, а этот файл не существует, нужно ли возбуждать исключение?
      Мы отвечаем следующим образом: "Это зависит от конкретного случая". Если файл должен был там находиться, то исключение гарантировано. Произошло что-то непредвиденное – файл, который вы считали существующим, похоже, исчез. С другой стороны, если вы понятия не имеете, должен ли этот файл существовать или нет, то его отсутствие уже не кажется столь исключительным и возвращение ошибки вполне уместно.
      Рассмотрим пример с первой ситуацией. Представленная ниже программа открывает файл /etc/passwd, который обязан существовать во всех системах Unix. Если файл не открывается, происходит передача исключения FileNotFoundException к вызывающей программе.
      public void open_passwd() throws FileNotFoundException {
      //При этом может возбуждаться FileNotFoundException…
        ipstream = new FilelnputStream("/efc/passwd");
        //…
      }
      Однако во второй ситуации может происходить открытие файла, указанного пользователем в командной строке. Здесь возбуждение исключения не гарантируется, и программа выглядит по-другому:
      public boolean open_user_file(String name)
        throws FileNotFoundException {
        File f = new File(name);
        if (!f.exists()) {
           return false;
        }
        ipstream = new FilelnputStream(f);
        return true;
      }
      Обратите внимание на то, что вызов FilelnputStream все еще способен генерировать исключение, передаваемое подпрограммой. Но при этом исключение будет сгенерировано лишь в действительно исключительных обстоятельствах; простая попытка открыть несуществующий файл сгенерирует обычное возвращение ошибки.
 

      Подсказка 34: Пользуйтесь исключениями только в исключительных случаях

 
      Почему мы предлагаем именно такой подход к исключениям? Конечно, исключение представляет собой мгновенную нелокальную передачу управления – своего рода многоуровневый оператор goto. Программы, использующие исключения в своей обычной работе, испытывают те же проблемы с удобочитаемостью и сопровождением, которые свойственны классическим неструктурированным программам. Эти программы нарушают инкапсуляцию: подпрограммы и их вызывающие программы отличаются более сильной связанностью за счет обработки исключений.

Обработчики ошибок как альтернатива исключению

      Обработчик ошибок представляет собой подпрограмму, которая вызывается при обнаружении ошибки. Вы можете зарегистрировать подпрограмму для обработки определенной категории ошибок. При возникновении одной из этих ошибок происходит вызов обработчика.
      Возникают ситуации, когда вам захочется применить обработчики ошибок вместо исключений или же одновременно с ними. Понятно, что, если вы работаете с языком С, не поддерживающим исключения, это один из нескольких возможных вариантов (см. Вопрос для обсуждения ниже). Но иногда обработчики ошибки могут использоваться даже в языках (типа Java), обладающих хорошей встроенной схемой обработки исключений.
      Рассмотрим реализацию приложения «клиент-сервер» с использованием средства RMI (удаленный вызов метода) в языке Java. Поскольку RMI реализован определенным способом, каждое обращение к удаленной подпрограмме должно быть подготовлено, с тем чтобы обработать ситуацию RemoteException. Добавление программы обработки этих исключений может представлять собой утомительную процедуру и означает сложность написания программы, которая могла бы работать как с локальными, так и с удаленными подпрограммами. Обойти эту трудность возможно путем инкапсулирования удаленных объектов в класс, не являющийся удаленным. Тогда этот класс сможет реализовать интерфейс обработчика ошибок, позволяя программе клиента регистрировать подпрограмму, обращение к. которой происходит при обнаружении удаленной исключительной ситуации.

Другие разделы, относящиеся к данной теме:

      • Мертвые программы не лгут

Вопросы для обсуждения

      • В языках программирования, не поддерживающих исключительные ситуации, часто используется иной (нелокальный) способ передачи механизма управления (например, в языке С существует средство longjmp/setjmp). Подумайте, как можно реализовать некий «суррогатный» механизм исключения, используя указанные средства. В чем состоят преимущества и опасности? Какие специальные меры необходимо предпринять для гарантии того, что эти ресурсы не «осиротеют»? Есть ли смысл использовать подобное решение всякий раз, когда вы пишете программу на языке С?

Упражнения

      21. При проектировании нового класса контейнера имеются три возможных состояния ошибки:
      1. Не хватает памяти для нового элемента в подпрограмме add.
      2. В подпрограмме fetch не обнаружена запрашиваемая точка входа.
      3. Указатель null передан к подпрограмме add.
      Каким образом необходимо обрабатывать каждую из этих ошибок? Нужна ли генерация ошибки, возбуждение исключительной ситуации, или же это состояние должно игнорироваться? (Ответ см. в Приложении В).

25
Балансировка ресурсов

      "Я привел тебя в этот мир", – сказал бы мой отец, – "я же могу и отправить тебя обратно. Мне это без разницы. Я сделаю еще одного такого, как ты".
Билл Косби, Отцовство

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