           try {
                  // работаем с f
              }
              catch (...) {
                  fclose(f);
                  throw;
              }
              fclose(f);
            }

 ‚сЯ часть функции, работающаЯ с файлом f, помещена в проверЯемый
 блок, в котором перехватываютсЯ все особые ситуации, закрываетсЯ
 файл и особаЯ ситуациЯ запускаетсЯ повторно.
     Ќедостаток этого решениЯ в его многословности, громоздкости
 и потенциальной расточительности. Љ тому же всЯкое многословное
 и громоздкое решение чревато ошибками, хотЯ бы в силу усталости
 программиста. Љ счастью, есть более приемлемое решение. ‚ общем
 виде проблему можно сформулировать так:

           void acquire()
           {
             // запрос ресурса 1
             // ...
             // запрос ресурса n

             // использование ресурсов

             // освобождение ресурса n
             // ...
             // освобождение ресурса 1
           }

 Љак правило бывает важно, чтобы ресурсы освобождались в обратном
 по сравнению с запросами порЯдке. ќто очень сильно напоминает порЯдок
 работы с локальными объектами, создаваемыми конструкторами и
 уничтожаемыми деструкторами. Џоэтому мы можем решить проблему запроса и
 освобождениЯ ресурсов, если будем использовать подходЯщие объекты
 классов с конструкторами и деструкторами. Ќапример, можно определить
 класс FilePtr, который выступает как тип FILE* :

           class FilePtr {
              FILE* p;
           public:
              FilePtr(const char* n, const char* a)
                { p = fopen(n,a); }
              FilePtr(FILE* pp) { p = pp; }
              ~FilePtr() { fclose(p); }

              operator FILE*() { return p; }
           };

 Џостроить объект FilePtr можно либо, имеЯ объект типа FILE*, либо,
 получив нужные длЯ fopen() параметры. ‚ любом случае этот
 объект будет уничтожен при выходе из его области видимости, и
 его деструктор закроет файл. ’еперь наш пример сжимаетсЯ до такой
 функции:

           void use_file(const char* fn)
           {
             FilePtr f(fn,"w");
             // работаем с f
           }

 „еструктор будет вызыватьсЯ независимо от того, закончилась ли функциЯ
 нормально, или произошел запуск особой ситуации.

        9.4.1 Љонструкторы и деструкторы

 Ћписанный способ управлениЯ ресурсами обычно называют "запрос ресурсов
 путем инициализации". ќто универсальный прием, рассчитанный на
 свойства конструкторов и деструкторов и их взаимодействие с
 механизмом особых ситуаций.
    Ћбъект не считаетсЯ построенным, пока не завершил выполнение его
 конструктор. ’олько после этого возможна раскрутка стека,
 сопровождающаЯ вызов деструктора объекта. Ћбъект, состоЯщий из
 вложенных объектов, построен в той степени, в какой построены
 вложенные объекты.
    •орошо написанный конструктор должен гарантировать, что объект
 построен полностью и правильно. …сли ему не удаетсЯ сделать это,
 он должен, насколько это возможно, восстановить состоЯние системы,
 которое было до начала построениЯ. „лЯ простых конструкторов было бы
 идеально всегда удовлетворЯть хотЯ бы одному условию - правильности
 или законченности объектов, и никогда не оставлЯть объект
 в "наполовину построенном" состоЯнии. ќтого можно добитьсЯ, если
 применЯть при построении членов способ "запроса ресурсов путем
 инициализации".
    ђассмотрим класс X, конструктору которого требуетсЯ два ресурса:
 файл x и замок y (т.е. монопольные права доступа к чему-либо).
 ќти запросы могут быть отклонены и привести к запуску особой
 ситуации. —тобы не усложнЯть работу программиста, можно потребовать,
 чтобы конструктор класса X никогда не завершалсЯ тем, что запрос на
 файл удовлетворен, а на замок нет. „лЯ представлениЯ двух видов
 ресурсов мы будем использовать объекты двух классов FilePtr и
 LockPtr (естественно, было бы достаточно одного класса, если x и y
 ресурсы одного вида). ‡апрос ресурса выглЯдит как инициализациЯ
 представлЯющего ресурс объекта:

           class X {
             FilePtr aa;
             LockPtr bb;
             // ...
             X(const char* x, const char* y)
                : aa(x),      // запрос `x'
                bb(y)         // запрос `y'
             { }
             // ...
           };

 ’еперь, как это было длЯ случаЯ локальных объектов, всю служебную
 работу, свЯзанную с ресурсами, можно возложить на реализацию.
 Џользователь не обЯзан следить за ходом такой работой. Ќапример,
 если после построениЯ aa и до построениЯ bb возникнет особаЯ
 ситуациЯ, то будет вызван только деструктор aa, но не bb.
      ќто означает, что если строго придерживатьсЯ этой простой
 схемы запроса ресурсов, то все будет в порЯдке. …ще более важно
 то, что создателю конструктора не нужно самому писать обработчики
 особых ситуаций.
      „лЯ требований выделить блок в свободной памЯти характерен самый
 произвольный порЯдок запроса ресурсов. Џримеры таких запросов уже
 неоднократно встречались в этой книге:

             class X {
               int* p;
               // ...
             public:
               X(int s) { p = new int[s]; init(); }
               ~X() { delete[] p; }
               // ...
             };

 ќто типичный пример использованиЯ свободной памЯти, но в совокупности с
 особыми ситуациЯми он может привести к ее исчерпанию памЯти.
 „ействительно, если в init() запущена особаЯ ситуациЯ, то отведеннаЯ
 памЯть не будет освобождена. „еструктор не будет вызыватьсЯ, поскольку
 построение объекта не было завершено. …сть более надежный вариант
 этого примера:

              template&lt;class T> class MemPtr {
              public:
                 T* p;
                 MemPtr(size_t s) { p = new T[s]; }
                 ~MemPtr() { delete[] p; }
                 operator T*() { return p; }
              }

              class X {
                 MemPtr&lt;int> cp;
                 // ...
              public:
                 X(int s):cp(s) { init(); }
                 // ...
              };

 ’еперь уничтожение массива, на который указывает p, происходит неЯвно
 в MemPtr. …сли init() запустит особую ситуацию, отведеннаЯ памЯть
 будет освобождена при неЯвном вызове деструктора длЯ полностью
 построенного вложенного объекта cp.
      Ћтметим также, что стандартнаЯ стратегиЯ выделениЯ памЯти в ‘++
 гарантирует, что если функции operator new() не удалось выделить памЯть
 длЯ объекта, то конструктор длЯ него никогда не будет вызыватьсЯ. ќто
 означает, что пользователю не надо опасатьсЯ, что конструктор или
 деструктор может быть вызван длЯ несуществующего объекта.
      ’еоретически дополнительные расходы, требующиесЯ длЯ обработки
 особых ситуаций, когда на самом деле ни одна из них не возникла, могут
 быть сведены к нулю. Ћднако, врЯд ли это верно длЯ ранних
 реализациЯх Языка. Џоэтому будет разумно в критичных внутренних циклах
 программы пока не использовать локальные переменные классов
 с деструкторами.

        9.4.2 ЏредостережениЯ

 Ќе все программы должны быть устойчивы ко всем видам ошибок. Ќе все
 ресурсы ЯвлЯютсЯ настолько критичными, чтобы оправдать попытки
 защитить их с помощью описанного способа "запроса ресурсов путем
 инициализации". …сть множество программ, которые просто читают
 входные данные и выполнЯютсЯ до конца. „лЯ них самой подходЯщей
 реакцией на динамическую ошибку будет просто прекращение счета
 (после выдачи соответствующего сообщениЯ). Ћсвобождение всех
 затребованных ресурсов возлагаетсЯ на систему, а пользователь
 должен произвести повторный запуск программы с более подходЯщими
 входными данными. Ќаша схема предназначена длЯ задач, в которых
 такаЯ примитивнаЯ реакциЯ на динамическую ошибку неприемлема.
 Ќапример, разработчик библиотеки обычно не в праве делать допущениЯ
 о том, насколько устойчива к ошибкам, должна быть программа,
 работающаЯ с библиотекой. Џоэтому он должен учитывать все динамические
 ошибки и освобождать все ресурсы до возврата из библиотечной функции
 в пользовательскую программу. Њетод "запроса ресурсов путем
 инициализации" в совокупности с особыми ситуациЯми, сигнализирующими
 об ошибке, может пригодитьсЯ при создании многих библиотек.

        9.4.3 €счерпание ресурса

 …сть одна из вечных проблем программированиЯ: что делать, если не
 удалось удовлетворить запрос на ресурс? Ќапример, в предыдущем
 примере мы спокойно открывали с помощью fopen() файлы и запрашивали с
 помощью операции new блок свободной памЯти, не задумываЯсь при этом,
 что такого файла может не быть, а свободнаЯ памЯть может исчерпатьсЯ.
 „лЯ решениЯ такого рода проблем у программистов есть два способа:
     Џовторный запрос: пользователь должен изменить свой запрос и
     повторить его.
     ‡авершение: запросить дополнительные ресурсы от системы, если
     их нет, запустить особую ситуацию.
 Џервый способ предполагает длЯ заданиЯ приемлемого запроса
 содействие пользователЯ, во втором пользователь должен быть готов
 правильно отреагировать на отказ в выделении ресурсов. ‚ большинстве
 случаев последний способ намного проще и позволЯет поддерживать в
 системе разделение различных уровней абстракции.
     ‚ ‘++ первый способ поддержан механизмом вызова функций, а
 второй - механизмом особых ситуаций. Ћба способа можно
 продемонстрировать на примере реализации и использованиЯ операции
 new:

            #include &lt;stdlib.h>

            extern void* _last_allocation;

            extern void* operator new(size_t size)
            {
              void* p;

              while ( (p=malloc(size))==0 ) {
                 if (_new_handler)
                    (*_new_handler)();  // обратимсЯ за помощью
                 else
                    return 0;
              }
              return _last_allocation=p;
            }

 …сли операциЯ new() не может найти свободной памЯти, она обращаетсЯ
 к управлЯющей функции _new_handler(). …сли в _new_handler() можно
 выделить достаточный объем памЯти, все нормально. …сли нет, из
 управлЯющей функции нельзЯ возвратитьсЯ в операцию new, т.к.
 возникнет бесконечный цикл. Џоэтому управлЯющаЯ функциЯ может
 запустить особую ситуацию и предоставить исправлЯть положение
 программе, обратившейсЯ к new:

            void my_new_handler()
            {
              try_find_some_memory();   // попытаемсЯ найти
                                        // свободную памЯть
              if (found_some()) return; // если она найдена, все в порЯдке
              throw Memory_exhausted(); // иначе запускаем особую
                                        // ситуацию "€счерпание_памЯти"
            }

 ѓде-то в программе должен быть проверЯемый блок с соответствующим
 обработчиком:

            try {
                // ...
            }
            catch (Memory_exhausted) {
                // ...
            }

     ‚ функции operator new() использовалсЯ указатель на управлЯющую
 функцию _new_handler, который настраиваетсЯ стандартной функцией
 set_new_handler(). …сли нужно настроитьсЯ на собственную управлЯющую
 функцию, надо обратитьсЯ так

           set_new_handler(&amp;my_new_handler);

 Џерехватить ситуацию Memory_exhausted можно следующим образом:

           void (*oldnh)() = set_new_handler(&amp;my_new_handler);

           try {
              // ...
           }
           catch (Memory_exhausted) {
              // ...
           }
           catch (...) {
              set_new_handler(oldnh);  // восстановить указатель на
                                       // управлЯющую функцию
              throw();      // повторный запуск особой ситуации
           }

           set_new_handler(oldnh); // восстановить указатель на
                                   // управлЯющую функцию

 Њожно поступить еще лучше, если к управлЯющей функции применить
 описанный в $$9.4 метод "запроса ресурсов путем инициализации" и
 убрать обработчик catch (...).
     ‚ решении, использующим my_new_handler(), от точки обнаружениЯ
 ошибки до функции, в которой она обрабатываетсЯ, не передаетсЯ
 никакой информации. …сли нужно передать какие-то данные, то
 пользователь может включить свою управлЯющую функцию в класс.
 ’огда в функции, обнаружившей ошибку, нужные данные можно поместить в
 объект этого класса. Џодобный способ, использующий объекты-функции,
 применЯлсЯ в $$10.4.2 длЯ реализации манипулЯторов. ‘пособ, в
 котором используетсЯ указатель на функцию или объект-функциЯ длЯ
 того, чтобы из управлЯющей функции, обслуживающей некоторый ресурс,
 произвести "обратный вызов" функции запросившей этот ресурс,
 обычно называетсЯ просто обратным вызовом (callback).
     Џри этом нужно понимать, что чем больше информации передаетсЯ
 из обнаружившей ошибку функции в функцию, пытающуюсЯ ее исправить,
 тем больше зависимость между этими двумЯ функциЯми. ‚ общем случае
 лучше сводить к минимуму такие зависимости, поскольку всЯкое
 изменение в одной из функций придетсЯ делать с учетом другой функцией,
 а, возможно, ее тоже придетсЯ изменЯть. ‚ообще, лучше не смешивать
 отдельные компоненты программы. Њеханизм особых ситуаций позволЯет
 сохранЯть раздельность компонентов лучше, чем обычный механизм вызова
 управлЯющих функций, которые задает функциЯ, затребовавшаЯ ресурс.
    ‚ общем случае разумный подход состоит в том, чтобы выделение
 ресурсов было многоуровневым (в соответствии с уровнЯми абстракции).
 Џри этом нужно избегать того, чтобы функции одного уровнЯ зависели
 от управлЯющей функции, вызываемой на другом уровне. Ћпыт созданиЯ
 больших программных систем показывает, что со временем удачные
 системы развиваютсЯ именно в этом направлении.

        9.4.4 Ћсобые ситуации и конструкторы

 Ћсобые ситуации дают средство сигнализировать о происходЯщих в
 конструкторе ошибках. Џоскольку конструктор не возвращает такое
 значение, которое могла бы проверить вызывающаЯ функциЯ, есть
 следующие обычные (т.е. не использующие особые ситуации) способы
 сигнализации:
     [1] ‚озвратить объект в ненормальном состоЯнии в расчете,
         что пользователь проверит его состоЯние.
     [2] “становить значение нелокальной переменной, которое
         сигнализирует, что создать объект не удалось.
 Ћсобые ситуации позволЯют тот факт, что создать объект не удалось,
 передать из конструктора вовне:

         Vector::Vector(int size)
         {
            if (sz&lt;0 || max&lt;sz) throw Size();
            // ...
         }

 ‚ функции, создающей вектора, можно перехватить ошибки, вызванные
 недопустимым размером (Size()) и попытатьсЯ на них отреагировать:

         Vector* f(int i)
         {
           Vector* p;
           try {
             p = new Vector v(i);
           }
           catch (Vector::Size) {
             // реакциЯ на недопустимый размер вектора
           }
           // ...
           return p;
         }

    “правлЯющаЯ созданием вектора функциЯ способна правильно
 отреагировать на ошибку. ‚ самом обработчике особой ситуации можно
 применить какой-нибудь из стандартных способов диагностики и
 восстановлениЯ после ошибки. Џри каждом перехвате особой ситуации
 в управлЯющей функции может быть свой взглЯд на причину ошибки. …сли
 с каждой особой ситуацией передаютсЯ описывающие ее данные, то объем
 данных, которые нужно анализировать длЯ каждой ошибки, растет. ЋсновнаЯ
 задача обработки ошибок в том, чтобы обеспечить надежный и удобный
 способ передачи данных от исходной точки обнаружениЯ ошибки до того
 места, где после нее возможно осмысленное восстановление.
     ‘пособ "запроса ресурсов путем инициализации" - самый надежное
 и красивое решение в том случае, когда имеютсЯ конструкторы, требующие
 более одного ресурса. Џо сути он позволЯет свести задачу выделениЯ
 нескольких ресурсов к повторно применЯемому, более простому, способу,
 рассчитанному на один ресурс.

        9.5 Ћсобые ситуации могут не быть ошибками

 …сли особаЯ ситуациЯ ожидалась, была перехвачена и не оказала
 плохого воздействиЯ на ход программы, то стоит ли ее называть
 ошибкой? ’ак говорЯт только потому, что программист думает о ней
 как об ошибке, а механизм особых ситуаций ЯвлЯетсЯ средством
 обработки ошибок. ‘ другой стороны, особые ситуации можно
 рассматривать просто как еще одну структуру управлениЯ. Џодтвердим
 это примером:

         class message { /* ... */ };   // сообщение

         class queue {        // очередь
            // ...
            message* get();   // вернуть 0, если очередь пуста
            // ...
         };

         void f1(queue&amp; q)
         {
           message* m = q.get();
           if (m == 0) {  // очередь пуста
              // ...
           }
           // используем m
         }

 ќтот пример можно записать так:

         class Empty { }  // тип особой ситуации "ЏустаЯ_очередь"

         class queue {
             // ...
             message* get();  // запустить Empty, если очередь пуста
             // ...
         };

         void f2(queue&amp; q)
         {
           try {
              message* m = q.get();
              // используем m
           }
           catch (Empty) {  // очередь пуста
              // ...
           }
         }

 ‚ варианте с особой ситуацией есть даже какаЯ-то прелесть. ќто
 хороший пример того, когда трудно сказать, можно ли считать
 такую ситуацию ошибкой. …сли очередь не должна быть пустой
 (т.е. она бывает пустой очень редко, скажем один раз из тысЯчи),
 и действиЯ в случае пустой очереди можно рассматривать как
 восстановление, то в функции f2() взглЯд на особую ситуацию будет
 такой, которого мы до сих пор и придерживались (т.е. обработка особых
 ситуаций есть обработка ошибок). …сли очередь часто бывает пустой,
 а принимаемые в этом случае действиЯ образуют одну из ветвей
 нормального хода программы, то придетсЯ отказатьсЯ от такого взглЯда
 на особую ситуацию, а функцию f2() надо переписать:

           class queue {
             // ...
             message* get();  // запустить Empty, если очередь пуста
             int empty();
             // ...
           };

           void f3(queue&amp; q)
           {
             if (q.empty()) { // очередь пуста
                // ...
             }
             else {
                message* m = q.get();
                // используем m
             }
           }

 Ћтметим, что вынести из функции get() проверку очереди на пустоту
 можно только при условии, что к очереди нет параллельных обращений.
     Ќе так то просто отказатьсЯ от взглЯда, что обработка особой
 ситуации есть обработка ошибки. Џока мы придерживаемсЯ такой точки
 зрениЯ, программа четко подразделЯетсЯ на две части: обычнаЯ часть
 и часть обработки ошибок. ’акаЯ программа более понЯтна. Љ сожалению,
 в реальных задачах провести четкое разделение невозможно, поэтому
 структура программы должна (и будет) отражать этот факт. „опустим,
 очередь бывает пустой только один раз (так может быть, если функциЯ
 get() используетсЯ в цикле, и пустота очереди говорит о конце цикла).
 ’огда пустота очереди не ЯвлЯетсЯ чем-то странным или ошибочным.
 Џоэтому, используЯ длЯ обозначениЯ конца очереди особую ситуацию,
 мы расширЯем представление об особых ситуациЯх как ошибках. ‘ другой
 стороны, действиЯ, принимаемые в случае пустой очереди, Явно отличаютсЯ
 от действий, принимаемых в ходе цикла (т.е. в обычном случае).
      Њеханизм особых ситуаций ЯвлЯетсЯ менее структурированным,
 чем такие локальные структуры управлениЯ как операторы if или for.
 Ћбычно он к тому же ЯвлЯетсЯ не столь эффективным, если особаЯ
 ситуациЯ действительно возникла. Џоэтому особые ситуации следует
 использовать только в том случае, когда нет хорошего решениЯ с более
 традиционными управлЯющими структурами, или оно, вообще, невозможно.
 Ќапример, в случае пустой очереди можно прекрасно использовать длЯ
 сигнализации об этом значение, а именно нулевое значение указателЯ на
 строку message, значит особаЯ ситуациЯ здесь не нужна. Ћднако, если бы
 из класса queue мы получали вместо указателЯ значение типа int, то
 то могло не найтись такого значениЯ, обозначающего пустую очередь.
 ‚ таком случае функциЯ get() становитсЯ эквивалентной операции
 индексации из $$9.1, и более привлекательно представлЯть пустую очередь
 с помощью особой ситуации. Џоследнее соображение подсказывает, что
 в самом общем шаблоне типа длЯ очереди придетсЯ длЯ обозначениЯ пустой
 очереди использовать особую ситуацию, а работающаЯ с очередью функциЯ
 будет такой:

          void f(Queue&lt;X>&amp; q)
          {
            try {
               for (;;) {  // ``бесконечный цикл''
                           // прерываемый особой ситуацией
                   X m = q.get();
                   // ...
               }
            }
            catch (Queue&lt;X>::Empty) {
                 return;
            }
          }

 …сли приведенный цикл выполнЯетсЯ тысЯчи раз, то он, по всей
 видимости, будет более эффективным, чем обычный цикл с проверкой
 условиЯ пустоты очереди. …сли же он выполнЯетсЯ только несколько
 раз, то обычный цикл почти навернЯка эффективней.
     ‚ очереди общего вида особаЯ ситуациЯ используетсЯ как способ
 возврата из функции get(). €спользование особых ситуаций как способа
 возврата может быть элегантным способом завершениЯ функций поиска.
 Ћсобенно это подходит длЯ рекурсивных функций поиска в дереве. Ћднако,
 применЯЯ особые ситуации длЯ таких целей, легко перейти грань разумного
 и получить маловразумительную программу. ‚се-таки всюду, где это
 действительно оправдано, надо придерживатьсЯ той точки зрениЯ, что
 обработка особой ситуации есть обработка ошибки. Ћбработка ошибок по
 самой своей природе занЯтие сложное, поэтому ценность имеют любые
 методы, которые дают Ясное представление ошибок в Языке и способ
 их обработки.

        9.6 ‡адание интерфейса

 ‡апуск или перехват особой ситуации отражаетсЯ на взаимоотношениЯх
 функций. Џоэтому имеет смысл задавать в описании функции множество
 особых ситуаций, которые она может запустить:

           void f(int a) throw (x2, x3, x4);

 ‚ этом описании указано, что f() может запустить особые ситуации
 x2, x3 и x4, а также ситуации всех производных от них типов, но
 больше никакие ситуации она не запускает. …сли функциЯ перечислЯет свои
 особые ситуации, то она дает определенную гарантию всЯкой вызывающей ее
 функции, а именно, если попытаетсЯ запустить иную особую ситуацию, то
 это приведет к вызову функции unexpected().
 ‘тандартное предназначение unexpected() состоит в вызове функции
 terminate(), котораЯ, в свою очередь, обычно вызывает abort().
 Џодробности даны в $$9.7.
      Џо сути определение

          void f() throw (x2, x3, x4)
          {
            // какие-то операторы
          }

 эквивалентно такому определению

          void f()
          {
            try {
              // какие-то операторы
            }
            catch (x2) {  // повторный запуск
             throw;
            }
            catch (x3) {  // повторный запуск
             throw;
            }
            catch (x4) {  // повторный запуск
             throw;
            }
            catch (...) {
             unexpected();
            }
          }

     Џреимущество Явного заданиЯ особых ситуаций функции в ее описании
 перед эквивалентным способом, когда происходит проверка на
 особые ситуации в теле функции, не только в более краткой записи.
 ѓлавное здесь в том, что описание функции входит в ее интерфейс,
 который видим длЯ всех вызывающих функций. ‘ другой стороны,
 определение функции может и не быть универсально доступным.
 „аже если у вас есть исходные тексты всех библиотечных функций,
 обычно желание изучать их возникает не часто.
    …сли в описании функции не указаны ее особые ситуации, считаетсЯ,
 что она может запустить любую особую ситуацию.

          int f();  // может запустить любую особую ситуацию

 …сли функциЯ не будет запускать никаких особых ситуаций, ее можно
 описать, Явно указав пустой список:

          int g() throw (); // не запускает никаких особых ситуаций

 Љазалось было бы логично, чтобы по умолчанию функциЯ не запускала
 никаких особых ситуаций. Ќо тогда пришлось бы описывать свои особые
 ситуации практически длЯ каждой функции ќто, как правило,
 требовало бы ее перетранслЯции, а кроме того препЯтствовало бы общению
 с функциЯми, написанными на других Языках. ‚ результате программист
 стал бы стремитьсЯ отключить механизм особых ситуаций и писал бы
 излишние операторы, чтобы обойти их. Џользователь считал бы такие
 программы надежными, поскольку мог не заметить подмены, но это было
 бы совершенно неоправдано.

        9.6.1 Ќеожиданные особые ситуации

 …сли к описанию особых ситуаций относитьсЯ не достаточно серьезно, то
 результатом может быть вызов unexpected(), что нежелательно во всех
 случаЯ, кроме отладки. €збежать вызова unexpected() можно, если хорошо
 организовать структуру особых ситуации и описание интерфейса. ‘
 другой стороны, вызов unexpected() можно перехватить и сделать его
 безвредным.
       …сли компонент Y хорошо разработан, все его особые ситуации
 могут быть только производными одного класса, скажем Yerr. Џоэтому,
 если есть описание

           class someYerr : public Yerr { /* ... */ };

 то функциЯ, описаннаЯ как

           void f() throw (Xerr, Yerr, IOerr);

 будет передавать любую особую ситуацию типа Yerr вызывающей функции.
 ‚ частности, обработка особой ситуации типа someYerr в f() сведетсЯ к
 передаче ее вызывающей f() функции.
       Ѓывает случаи, когда окончание программы при поЯвлении
 неожиданной особой ситуации ЯвлЯетсЯ слишком строгим решением.
 „опустим функциЯ g() написана длЯ несетевого режима в распределенной
 системе. …стественно, в g() ничего неизвестно об особых ситуациЯх,
 свЯзанных с сетью, поэтому при поЯвлении любой из них вызываетсЯ
 unexpected(). ‡начит длЯ использованиЯ g() в распределенной системе
 нужно предоставить обработчик сетевых особых ситуаций или переписать
 g(). …сли допустить, что переписать g() невозможно или нежелательно,
 проблему можно решить, переопределив действие функции unexpected().
 „лЯ этого служит функциЯ set_unexpected(). ‚начале мы определим
 класс, который позволит нам применить длЯ функций unexpected()
 метод "запроса ресурсов путем инициализации" :

           typedef void(*PFV)();
           PFV set_unexpected(PFV);

           class STC {   // класс длЯ сохранениЯ и восстановлениЯ
             PFV old;    // функций unexpected()
           public:
             STC(PFV f) { old = set_unexpected(f); }
             ~STC() { set_unexpected(old); }
           };

 ’еперь мы определим функцию, котораЯ должна в нашем примере заменить
 unexpected():

           void rethrow() { throw; }  // перезапуск всех сетевых
                                      // особых ситуаций

 Ќаконец, можно дать вариант функции g(), предназначенный длЯ работы
 в сетевом режиме:

           void networked_g()
           {
            STC xx(&amp;rethrow); // теперь unexpected() вызывает rethrow()
            g();
           }

 ‚ предыдущем разделе было показано, что unexpected() потенциально
 вызываетсЯ из обработчика catch (...). ‡начит в нашем случае
 обЯзательно произойдет повторный запуск особой ситуации. Џовторный
 запуск, когда особаЯ ситуациЯ не запускалась, приводит к вызову
 terminate(). Џоскольку обработчик catch (...) находитсЯ вне той
 области видимости, в которой была запущена сетеваЯ особаЯ ситуациЯ,
 бесконечный цикл возникнуть не может.
     …сть еще одно, довольно опасное, решение, когда на неожиданную
 особую ситуацию просто "закрывают глаза":

          void muddle_on() { cerr &lt;&lt; "не замечаем особой ситуации\n"; }
          // ...
          STC xx(&amp;muddle_on);  // теперь действие unexpected() сводитсЯ
                               // просто к печати сообщениЯ

 ’акое переопределение действиЯ unexpected() позволЯет нормально
 вернутьсЯ из функции, обнаружившей неожиданную особую ситуацию.
 ЌесмотрЯ на свою очевидную опасность, это решение используетсЯ.
 Ќапример, можно "закрыть глаза" на особые ситуации в одной части
 системы и отлаживать другие ее части. ’акой подход может быть
 полезен в процессе отладки и развитиЯ системы, перенесенной с Языка
 программированиЯ без особых ситуаций. ‚се-таки, как правило лучше,
 если ошибки проЯвлЯютсЯ как можно раньше.
     ‚озможно другое решение, когда вызов unexpected() преобразуетсЯ
 в запуск особой ситуации Fail (неудача):

          void fail() { throw Fail; }
          // ...
          STC yy(&amp;fail);

 Џри таком решении вызывающаЯ функциЯ не должна подробно разбиратьсЯ в
 возможном результате вызываемой функции: эта функции завершитсЯ
 либо успешно (т.е. возвратитсЯ нормально), либо неудачно (т.е.
 запустит Fail). Ћчевидный недостаток этого решениЯ в том, что
 не учитываетсЯ дополнительнаЯ информациЯ, котораЯ может сопровождать
 особую ситуацию. ‚прочем, при необходимости ее можно учесть, если
 передавать информацию вместе с Fail.

        9.7 Ќеперехваченные особые ситуации

 …сли особаЯ ситуациЯ запущена и не перехвачена, то вызываетсЯ функциЯ
 terminate(). Ћна же вызываетсЯ, когда система поддержки особых
 ситуаций обнаруживает, что структура стека нарушена, или когда
 в процессе обработки особой ситуации при раскручивании стека вызываетсЯ
 деструктор, и он пытаетсЯ завершить свою работу, запустив особую
 ситуацию.
      „ействие terminate() сводитсЯ к выполнению самой последней
 функции, заданной как параметр длЯ set_terminate():

            typedef void (*PFV)();
            PFV set_terminate(PFV);

 ”ункциЯ set_terminate() возвращает указатель на ту функцию, котораЯ
 была задана как параметр в предыдущем обращении к ней.
       Ќеобходимость такой функции как terminate() объЯснЯетсЯ тем,
 что иногда вместо механизма особых ситуаций требуютсЯ более
 грубые приемы. Ќапример, terminate() можно использовать длЯ
 прекращениЯ процесса, а, возможно, и длЯ повторного запуска системы.
 ќта функциЯ служит экстренным средством, которое применЯетсЯ, когда
 отказала стратегиЯ обработки ошибок, рассчитаннаЯ на особые
 ситуации, и самое времЯ применить стратегию более низкого уровнЯ.
       ”ункциЯ unexpected() используетсЯ в сходных, но не столь
 серьезных случаЯх, а именно, когда функциЯ запустила особую ситуацию,
 не указанную в ее описании. „ействие функции unexpected() сводитсЯ
 к выполнению самой последней функции, заданной как параметр длЯ
 функции set_unexpected().
       Џо умолчанию unexpected() вызывает terminate(), а та, в свою
 очередь, вызывает функцию abort(). ЏредполагаетсЯ, что такое соглашение
 устроит большинство пользователей.
       ЏредполагаетсЯ, что функциЯ terminate() не возвращаетсЯ в
 обратившеюсЯ  ней функцию.
       Ќапомним, что вызов abort() свидетельствует о ненормальном
 завершении программы. „лЯ нормального выхода из программы
 используетсЯ функциЯ exit(). Ћна возвращает значение, которое
 показывает окружающей системе насколько корректно закончилась программа.

        9.8 „ругие способы обработки ошибок

 Њеханизм особых ситуаций нужен длЯ того, чтобы из одной части
 программы можно было сообщить в другую о возникновении в первой
 "особой ситуации". Џри этом предполагаетсЯ, что части программы
 написаны независимо друг от друга, и в той части, котораЯ
 обрабатывает особую ситуацию, возможна осмысленнаЯ реакциЯ на
 ошибку.
      Љак же должен быть устроен обработчик особой ситуации? Џриведем
 несколько вариантов:

           int f(int arg)
           {
              try {
                 g(arg);
              }
              catch (x1) {
                 // исправить ошибку и повторить
                 g(arg);
              }
              catch (x2) {
                 // произвести вычислениЯ и вернуть результат
                 return 2;
              }
              catch (x3) {
                 // передать ошибку
                 throw;
              }
              catch (x4) {
                 // вместо x4 запустить другую особую ситуацию
                 throw xxii;
              }
              catch (x5) {
                 // исправить ошибку и продолжить со следующего оператора
              }
              catch (...) {
                 // отказ от обработки ошибки
                 terminate();
              }
              // ...
            }

 “кажем, что в обработчике доступны переменные из области видимости,
 содержащей проверЯемый блок этого обработчика. Џеременные,
 описанные в других обработчиках или других проверЯемых блоках,
 конечно, недоступны:

             void f()
             {
               int i1;
               // ...
               try {
                  int i2;
                  // ...
               }
               catch (x1) {
                  int i3;
                  // ...
               }
               catch (x4) {
                  i1 = 1;   // нормально
                  i2 = 2;   // ошибка: i2 здесь невидимо
                  i3 = 3;   // ошибка: i3 здесь невидимо
               }
             }

 Ќужна общаЯ стратегиЯ длЯ эффективного использованиЯ обработчиков в
 программе. ‚се компоненты программы должны согласованно использовать
 особые ситуации и иметь общую часть длЯ обработки ошибок. Њеханизм
 обработки особых ситуаций ЯвлЯетсЯ нелокальным по своей сути,
 поэтому так важно придерживатьсЯ общей стратегии. ќто предполагает,
 что стратегиЯ обработки ошибок должна разрабатыватьсЯ на самых
 ранних стадиЯх проектах. Љроме того, эта стратегиЯ должна
 быть простой (по сравнению со сложностью всей программы) и Ясной.
 Џоследовательно проводить сложную стратегию в такой сложной
 по своей природе области программированиЯ, как восстановление после
 ошибок, будет просто невозможно.
      Џрежде всего стоит сразу отказатьсЯ от того, что одно средство
 или один прием можно применЯть длЯ обработки всех ошибок. ќто
 только усложнит систему. “дачнаЯ система, обладающаЯ устойчивостью
 к ошибкам, должна строитьсЯ как многоуровневаЯ. Ќа каждом уровне
 надо обрабатывать настолько много ошибок, насколько это возможно
 без нарушениЯ структуры системы, оставлЯЯ обработку других ошибок более
 высоким уровнЯм. Ќазначение terminate() поддержать такой подход,
 предоставлЯЯ возможность экстренного выхода из такого положениЯ,
 когда нарушен сам механизм обработки особых ситуаций, или когда
 он используетсЯ полностью, но особаЯ ситуациЯ оказалась
 неперехваченной. ”ункциЯ unexpected() предназначена длЯ выхода из
 такого положениЯ, когда не сработало основанное на описании всех особых
 ситуаций средство защиты. ќто средство можно представлЯть как брандмауер,
 т.е. стену, окружающую каждую функцию, и препЯтствующую
 распространению ошибки. Џопытка проводить в каждой функции полный
 контроль, чтобы иметь гарантию, что функциЯ либо успешно завершитсЯ,
 либо закончитсЯ неудачно, но одним из определенных и корректных
 способов, не может принести успех. Џричины этого могут быть различными
 длЯ разных программ, но длЯ больших программ можно назвать следующие:
   [1] работа, которую нужно провести, чтобы гарантировать надежность
       каждой функции, слишком велика, и поэтому ее не удастсЯ
       провести достаточно последовательно;
   [2] поЯвЯтсЯ слишком большие дополнительные расходы памЯти и времени,
       которые будут недопустимы длЯ нормальной работы системы
       (будет тенденциЯ неоднократно проверЯть на одну и ту же ошибку,
        а значит постоЯнно будут проверЯтьсЯ переменные с правильными
        значениЯми);
   [3] таким ограничениЯм не будут подчинЯтьсЯ функции, написанные на
       других Языках;
   [4] такое понЯтие надежности ЯвлЯетсЯ чисто локальным и оно
       настолько усложнЯет систему, что становитсЯ дополнительной
       нагрузкой длЯ ее общей надежности.
    Ћднако, разбить программу на отдельные подсистемы, которые либо
 успешно завершаютсЯ, либо заканчиваютсЯ неудачно, но одним из
 определенных и корректных способов, вполне возможно, важно и даже
 выгодно. ’аким свойством должны обладать основные библиотеки,
 подсистемы или ключевые функции. Ћписание особых ситуаций должно
 входить в интерфейсы таких библиотек или подсистем.
    €ногда приходитсЯ от одного стилЯ реакции на ошибку переходить
 на другой. Ќапример, можно после вызова стандартной функции ‘
 проверЯть значение errno и, возможно, запускать особую ситуацию,
 а можно, наоборот, перехватывать особую ситуацию и устанавливать
 значение errno перед выходом из стандартной функции в ‘-программу:

             void callC()
             {
               errno = 0;
               cfunction();
               if (errno) throw some_exception(errno);
             }

             void fromC()
             {
               try {
                  c_pl_pl_function();
               }
               catch (...) {
                  errno = E_CPLPLFCTBLEWIT;
               }
             }

 Џри такой смене стилей важно быть последовательным, чтобы изменение
 реакции на ошибку было полным.
     Ћбработка ошибок должна быть, насколько это возможно, строго
 иерархической системой. …сли в функции обнаружена динамическаЯ
 ошибка, то не нужно обращатьсЯ за помощью длЯ восстановлениЯ или
 выделениЯ ресурсов к вызывающей функции. Џри таких обращениЯх в
 структуре системы возникают циклические зависимости, в результате
 чего ее труднее понЯть, и возможно возникновение бесконечных
 циклов в процессе обработки и восстановлениЯ после ошибки.
    —тобы часть программы, предназначеннаЯ длЯ обработки ошибок
 была более упорЯдоченной, стоит применЯть такие упрощающие дело
 приемы, как "запрос ресурсов путем инициализации", и исходить из
 таких упрощающих дело допущений, что "особые ситуации ЯвлЯютсЯ
 ошибками".

        9.9 “пражнениЯ

 1. (*2) Ћбобщите класс STC до шаблона типа, который позволЯет
    хранить и устанавливать функции разных типов.
 2. (*3) „ополните класс CheckedPtrToT из $$7.10 до шаблона типа, в
    котором особые ситуации сигнализируют о динамических ошибках.
 3. (*3) Ќапишите функцию find длЯ поиска в бинарном дереве узлов
    по значению полЯ типа char*. …сли найден узел с полем, имеющим
    значение "hello", она должна возвращать указатель на него. „лЯ
    обозначениЯ неудачного поиска используйте особую ситуацию.
 4. (*1) Ћпределите класс Int, совпадающий во всем со встроенным
    типом int за исключением того, что вместо переполнениЯ или
    потери значимости в этом классе запускаютсЯ особые ситуации.
    Џодсказка: см. $$9.3.2.
 5. (*2) Џеренесите из стандартного интерфейса ‘ в вашу операционную
    систему основные операции с файлами: открытие, закрытие, чтение и
    запись. ђеализуйте их как функции на ‘++ с тем же назначением,
    что и функций на ‘, но в случае ошибок запускайте особые
    ситуации.
 6. (*1) Ќапишите полное определение шаблона типа Vector с особыми
    ситуациЯми Range и Size. Џодсказка: см. $$9.3.
 7. (*1) Ќапишите цикл длЯ вычислениЯ суммы элементов вектора,
    определенного в упражнении 6, причем не проверЯйте размер вектора.
    Џочему это плохое решение?
 8. (*2.5) „опустим класс Exception используетсЯ как базовый длЯ всех
    классов, задающих особые ситуации. Љаков должен быть его вид?
    ЉакаЯ от него могла быть польза? Љакие неудобства может вызвать
    требование обЯзательного использованиЯ этого класса?
 9. (*2) Ќапишите класс или шаблон типа, который поможет реализовать
    обратный вызов.
 10. (*2) Ќапишите класс Lock (замок) длЯ какой-нибудь системы,
    допускающей параллельное выполнение.
 11. (*1) Џусть определена функциЯ
         int main() { /* ... */ }
    €змените ее так, чтобы в ней перехватывались все особые ситуации,
    преобразовывались в сообщениЯ об ошибке и вызов abort().
    Џодсказка: в функции fromC() из $$9.8 учтены не все случаи.


         * ѓ‹Ђ‚Ђ 10. ЏЋ’ЋЉ€

                "„оступно только то, что видимо"
                           Ѓ. Љерниган

    ‚ Языке ‘++ нет средств длЯ ввода-вывода. €х и не нужно, поскольку
такие средства можно просто  и  элегантно  создать  на  самом  Языке.
ЋписаннаЯ здесь библиотека потокового ввода-вывода реализует строгий
типовой и вместе с тем гибкий и эффективный способ символьного ввода и
вывода целых, вещественных чисел и символьных строк, а также ЯвлЯетсЯ
базой длЯ расширениЯ, рассчитанного на работу с пользовательскими типами
данных. Џользовательский интерфейс библиотеки находитсЯ в файле
&lt;iostream.h>. ќта глава посвЯщена самой потоковой библиотеке, некоторым
способам работы с ней и определенным приемам реализации библиотеки.

        10.1  ‚‚…„…Ќ€…

ироко известна трудность задачи проектированиЯ и реализации
стандартных средств ввода-вывода длЯ Языков программированиЯ.
’радиционно средства ввода-вывода были  рассчитаны  исключительно  на
небольшое  число встроенных типов данных. Ћднако, в нетривиальных
программах на ‘++ есть много пользовательских типов данных, поэтому
необходимо предоставить
возможность ввода-вывода значений таких типов. Ћчевидно, что средства
ввода-вывода должны быть простыми, удобными, надежными в использовании
и, что важнее всего, адекватными. Џока никто не нашел решениЯ, которое
удовлетворило бы всех; поэтому необходимо дать возможность пользователю
создавать иные средства ввода-вывода, а также расширЯть стандартные
средства ввода-вывода в расчете на определенное применение.
   –е