The Russian Electronic Developer Magazine
	Русский электронный журнал разработчика

Работа над ошибками.

"Точно так же все верят в свою исключительность..."
А. Макаревич

Дмитpий Завалишин
( Dmitry Zavalishin <dz@phantom.ru> )

$Id: except.txt 1.7 1997/03/10 10:52:08 dz Exp $

(Подводка)

Банальность на тему: ничто не дается даром. С использованием exceptions исчезает одна головная боль, и приходит несколько других. Поначалу кажется, что новые проблемы еще хуже старых, однако при ближайшем рассмотрении многие из них оказываются не столько проблемами, сколько результатом попытки смешения стилей. Автор Си++ справедливо утверждал, что программировать на нем можно опираясь на несколько совершенно разных подходов. Я добавлю, что держать себя в рамках одного из них - весьма полезно. Это следует как из соображений абстрактых (никому еще от эклектики особого добра не было), так и сугубо практических. Поскольку почти все люди, способные внять абстрактным доводам способны их же и породить самостоятельно :), остановлюсь на вторых. Да оно и интереснее, в данном случае.

Предистория

Hе знаю, что сподвигло автора концепции исключительных ситуаций ее придумать, но лично меня к этому дело привела жестокая лень писать в сотнях закоулков одно и то же снова и снова: "if( do_that() == Err ) return Err;". Ладно бы просто лень набить лишний if - так ведь дело этим не кончается. Hужно еще и не забыть освободить ресурсы, занятые данной функцией, а если они захватываются по очереди и их много - и вообще застрелиться можно. Самый простой код в этом случае выглядит примерно так:

Пример 1. 

int do_that()
  {
  int got = 0;

  if( get_r1() != Err )
    {
    got++;
    if( get_r2() != Err )
      {
      got++;
      if( get_r3() != Err )
        {
        got++;     
        ... здесь, собственно, работаем, используем ресурсы ...
        }
      }
    }

  switch( got )
    {
    case 3:  release_r3(); // fall through!
    case 2:  release_r2(); // fall through!
    case 1:  release_r1(); // fall through!
    }

  }

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

Пример 2.

void do_that()
  {
  r1_allocator r1;
  r2_allocator r2;
  r3_allocator r3;

  ... здесь, собственно, работаем, используем ресурсы ...

  }

Ошибкология

"Шахтеры делают ЭТО под землей"
(C) Yuri PQ :)

Как это делают в C++

Пример 3.

try
   {
   ...какой-то код, при исполнении которого 
      могут возникнуть проблемы...
   }
catch( тип_облома )
   {
   ...что сделать, если в теле блока try, таки, 
        случились неприятности...
   }

Пример 4.

class io_exception {};
class record{ ... };

// Прочесть новую запись из потока, 
// построить и вернуть объект
record::record( istream &i )
    {
    ...
    i.read( .... );
    if( i.bad() ) throw io_exception();
    ...
    }

other_func()
    {
    try
        {
        rec_list.insert( new record( data_stream ) );
        }
    catch( io_exception )
        {
        print_error("Can't read a record");
        throw;
        }
    }

Пример 5 - тот-же код, что и в примере 4, но без использования исключений.

// Прочесть новую запись из потока,
// построить и вернуть объект
bool record::read( istream &i )
    {
    ...
    i.read( .... );
    if( i.bad() ) return Err;
    return Ok;
    }

other_func()
    {
    record r = new record( data_stream )
    if( r == NULL ) return Err;

    if( r.read() == Err )
        {
        delete r;
        print_error("Can't read a record");
        return Err;
        }

    if( rec_list.insert( r ) == Err )
        {
        print_error("Can't insert a record");
        return Err;
        }
    return Ok;
    }

Посмотрите - то, что в варианте с исключениями выражалось одним простым оператором rec_list.insert( new record( data_stream ) ) теперь тянет на несколько строк, по которым рамазана и без того тощая его сущность. Конечно, читатель имеет право возразить - зато в варианте с исключениями торчит этот безумный try и огромный catch-хвост свисает, так что экономия не так и велика. Поверьте, пока что, на слово - в примерах обработка исключений выглядит страшнее, чем в реальности. Ведь если действительно уметь пользоваться исключениями, try и catch будут встречаться не так уж часто, а некоторые из них и вообще превратятся в элементарщину типа

Пример 6.

while(1)
    {
    try { l.load( f ); } catch(Ex_EOF) { break; }
    ...
    }

Это просто класс!

Пример 7.

class General_Ex 
    {
    public:
        string   where, what, why;
        void print() const;
    };

class Ex_Abort : public General_Ex
    {
    public:
        Ex_Abort( const char* wh )
            { where = wh; what = "operation aborted"; why = ""; }
    };


class Ex_EOF : public General_Ex
    {
    public:
        Ex_EOF( const char* wh )
            { where = wh; what = "EOF"; why = ""; }
    };


class Ex_Fail : public General_Ex
    {
    public:
        Ex_Fail( const char* wh, const char* wa, const char* wy )
            { where = wh; what = wa; why = wy; }
    };

class Ex_Errno : public General_Ex
    {
    public:
        Ex_Errno( const char* wh, const char* wa, long e = errno() )
            {
            where = wh; what = wa;
            char es[100]; sprintf( es, "%ld", e ); why = es;
            }
    };

Пример 8.

try { ..... throw( Ex_Fail("db cleaner", 
     "out of alcohol, nothiong to clean with","")); ... }
catch( General_Ex ex ) { ex.print(); }

Следствия

Пример 9.

void read_file()
    {
    FILE *fp = fopen( ... );
    if( !fp ) 
	throw( Ex_Errno("read_file", "can't open file" ));

    try 
        {
 ... читаем файл ...
        }
    catch(...) // поймаем любое исключение
        {
        fclose( fp );
        throw; // кинем то-же самое исключение дальше
        }
    // сюда попадем, если исключений не было
    fclose(fp);
    }      

Пример 10.

void read_file()
    {
    ifstream is( filename ); 
// К сожалению, ifstream не умеет бросать  исключение сам
    if( !fp ) throw( Ex_Errno("read_file", "can't open file" ));
// придется помочь ему

    ... читаем файл ...
    }      

Hу, ладно, хоршо - с файлами так можно. А если, к примеру, семафор потребовался? Hичего страшного - маленький простенький класс-обертка решит проблему с семафором не менее изящно. Предположим, у нас есть класс SpinLock (замок), объекты которого являются семафорами. Захват семафора производится вызовом метода lock(), освобождение - unlock().

Пример 11, замок, он же - семафор.

class SpinLock
    {
    private:
       unsigned long  h;

    public:
       SpinLock();
       ~SpinLock(); // { unlock(); }

    protected:
       friend class SLKey;
       void lock();   // Wait for resource and lock it
       void unlock(); // Release

    };

Пример 12, ключ к замку.

class SLKey
    {
    SpinLock ≪
    public:
       SLKey( SpinLock &l ) : ll(l) { ll.lock();   }
       ~SLKey(  )                   { ll.unlock(); }
    };

void func_with_a_sema_locked_section()
    {
    extern SpinLock  log_file_access_sema;

    ... делаем что-либо некритичное ...

        { // этот блок защищен семафором
        SLKey mykey(log_file_access_sema); 
        // с этого момента семафор log_file_access_sema заперт

        ... выполняем критичную часть кода ...
        }
    ... здесь семафор снова не заперт ...
    }

Подводные камни и общие соображения

Второе, о чем нужно помнить, как я уже говорил выше - longjmp для выхода из функций использовать нельзя. Это не представляет проблемы - вместо longjmp можно использовать exception-же.
Обращайте внимание на то, как часто у вас встречается catch. Каждое его использование должно быть объяснимо с точки зрения логики алгоритма, а не ваших кодировочных потребностей. Если встречается "технический", необъяснимый с позиции постановки задачи catch - значит, что-то неладно в дизайне программы. К примеру, в моем коде catch встречается примерно один раз на 250 строк. Конечно, это зависит от задачи, но порядок величиныЮ думаю, вряд ли будет иным при правильном использовании методики. Все, что вы прочитали в этой статье было выяснено, опробовано и отточено при написании с нуля примерно 15000 строк кода и при переработке с применением exceptions других 25000 строк кода. Думаю, это дает мне право сказать с основанием - рекомендую.

(c) 1997 dz

Интересные ссылки:

Комментариев к странице: 0 | Добавить комментарий

Редактор: Дмитрий Бан
Оформление: Евгений Кулешов