Переброска исключений по цепочке.

[RXL]

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

Код:

void method()
{
  try
  {
    lock();
    // some actions...
    unlock();
  }
  catch (Exception &e)
  {
    unlock(); // исключения ловим из-за него

    // теперь надо передать пойманное исключение дальше, не изменяя его.
  }
}

Как можно бросить исключение дальше, не создавая нового объекта?
Условие такое: Exception - базовый класс для исключений.


Дополнение: у меня BCB6. Особенность VCL-классов в том, что они исключительно динамически создаваемые и VCL-исключения обрабатываются только по ссылке.
Нашел таки в доке пример:

Код:

catch (Exception &e)
{
  // обработка
  throw; // переброска
}

[Алексей++]

вроде бы так

-дезинформация удалена )) -

[RXL]

Леш, я так пробовал. К моменту броска объект по ссылке умирает и дальше летит гарантированный segmentaion fault.

Дополнил первый пост примером, как Борланд предлагают перебрасывать.


А method() throw(....) вообще здесь не причем Це только декларация и никаких действий не предписано.

[Алексей++]

ага, нашёл, кажись

мсдн говорит

A throw-expression with no operand re-throws the exception currently being handled. Such an expression should appear only in a catch handler or in a function called from within a catch handler. The re-thrown exception object is the original exception object (not a copy). For example:


try
 {
   throw CSomeOtherException();
}
catch(...) {  // Handle all exceptions
   // Respond (perhaps only partially) to exception
   throw;       // Pass exception to some other handler
}
 

[Джон]

Не, Ром, всё правильно. Именно throw; жаль я раньше тему не видел. Но последние минут 10 к российским ресурсам (многим во всяком случае) не было доступа. На форум не мог зайти. Куча линков не открывалась. Ща вроде работает.

[RXL]

Успокоили А то мало ли чего Борланд напридумывал...
Под рукой только борландовская дока. Страуструп дома на диване отдыхает, а лезть в MSDN по пустякам - много времени потерять.

[Антон (LogRus)]

Offtopic:

Код:

void method()
{
  try
  {
    lock();
    // some actions...
    unlock();
  }
  catch (Exception &e)
  {
    unlock(); // исключения ловим из-за него

    // теперь надо передать пойманное исключение дальше, не изменяя его.
  }
}

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


а по теме уже всё сказано

[Dimka]

я бы использовал RAII

Если систематически, то имеет смысл завести некий SyncObject с lock в конструкторе и unlock в деструкторе. Но бывают одноразовые случаи, когда так делать - только неоправданно усложнять.

[RXL]

Как раз и используется критическая секция в некоторых методах в объекте.

Другой случай: SQL-запрос с переменными подстановки и Commit в try и Rollback и DeleteVariables в catch. Но в таком случае я ошибки на месте обрабатываю и дальше уже кидаю что-то осмысленное.

[sss]

RXL, действительно, если передавать статический объект исключения, он будет очищен при выходе из зоны видимости
1) в CBuilder да! Зона видимости кончается пределами той функции, в которой объявлено исключение.
2) в VC  - не понятно! Нет! Когда происходит (и происходит ли) очистка не помню (не знаю).
В своё время очень много пришлось переделывать - я протаскиваю свою библиотеку кодов, так, что бы  она одинаково работала как в BCB, так и в VC.

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

Код:

void some1(void) throw (ESystemError*)
{
  try
  {
    throw new __ESystemError( ::GetLastError());
  }
  catch(...)
  {
    ...
    throw;
  }
}  
void main(void)
{
   try
  {
    some1();
  }
  catch( EExcept* e)
  {
    SHOWTHROW( e);
    e->Release();
  }
}

[Антон (LogRus)]

...........только неоправданно усложнять.

это иллюзия надо написать 3 строчки кода убрав при этом 3 другие, вопрос в чём сложность?

Как раз и используется критическая секция в некоторых методах в объекте.

Эммм, не понял к чему это..

Другой случай: SQL-запрос с переменными подстановки и Commit в try и Rollback и DeleteVariables в catch. Но в таком случае я ошибки на месте обрабатываю и дальше уже кидаю что-то осмысленное.

Ну это отдельный случай, т.к. оракл использует C интрфейс (в стандартной OCI) и там нет исключений. Но ты же наверняка уже написал свою обёртку на CPP вокруг OCI

RXL, действительно, если передавать статический объект исключения, он будет очищен при выходе из зоны видимости
1) в CBuilder да! Зона видимости кончается пределами той функции, в которой объявлено исключение.
2) в VC  - не понятно! Нет! Когда происходит (и происходит ли) очистка не помню (не знаю).

что нам говорит стандарт:

The memory for the exception object is allocated in an unspecified way, except as noted in 3.7.4.1. If a
handler exits by rethrowing, control is passed to another handler for the same exception. The exception
object is destroyed after either the last remaining active handler for the exception exits by any means other
than rethrowing, or the last object of type std::exception_ptr (18.8.5) that refers to the exception object is
destroyed, whichever is later. In the former case, the destruction occurs when the handler exits, immediately
after the destruction of the object declared in the exception-declaration in the handler, if any. In the latter
case, the destruction occurs before the destructor of std::exception_ptr returns. The implementation
may then deallocate the memory for the exception object; any such deallocation is done in an unspecified
way.

Я работаю с VC++ 2003 и GCC, и всегда выбрасываю исключения так

Код:

throw Expetion(params);

и ловлю на зависимо от того, как далеко обработчик исключения (в стеке вызовов, рядом с точкой выброса или на 20 функции вверх)

Код:

catch(const Exception & e)

проблем с обработкой исключений не разу не наблюдал

[sss]

LogRus, вот вот... Я тоже проблем не наблюдал, пока тот же самый код не перенес в CBuilder. Там маленько сложнее. Если не изменяет память, в момент регенерации исключения, сам объект исключения повторно копируется в новый экземпляр (используя копирующий конструктор).

[RXL]

Как раз и используется критическая секция в некоторых методах в объекте.

Эммм, не понял к чему это..

Я использую блокировку в некоторых методах - критическую секцию - и из-за нее и задумался о перехвате исключений и последующей передачи из дальше.

Другой случай: SQL-запрос с переменными подстановки и Commit в try и Rollback и DeleteVariables в catch. Но в таком случае я ошибки на месте обрабатываю и дальше уже кидаю что-то осмысленное.

Ну это отдельный случай, т.к. оракл использует C интрфейс (в стандартной OCI) и там нет исключений. Но ты же наверняка уже написал свою обёртку на CPP вокруг OCI

Использую VCL-компоненты Oracle DAO для BCB - там уже все объектное, хотя большой разницы с процедурным подходом не видно - только исключения вносят разнообразие. Обертку я тоже написал, но уже поверх DAO, для уменьшения телодвижений, повышения надежности и с более удобным управлением пулом сессий.

LogRus, вот вот... Я тоже проблем не наблюдал, пока тот же самый код не перенес в CBuilder. Там маленько сложнее. Если не изменяет память, в момент регенерации исключения, сам объект исключения повторно копируется в новый экземпляр (используя копирующий конструктор).

Можно проверить, сделав свой класс исключения и подсчитать количество созданных объектов.

[Антон (LogRus)]

Я использую блокировку в некоторых методах - критическую секцию - и из-за нее и задумался о перехвате исключений и последующей передачи из дальше.

Если ты отлов исключения используешь для снятия блокировки и с последующим перевыбросом исключения, то правильней использовать RAII, например, реализация boost::mutex использует критическую секцию, как базовый примитив и RAII для установки и снятия блокировок

[sss]

Гм, LogRus а если

Код:

catch(const Exception & e)

заменить на

Код:

catch(Exception & e)

Проблем то же не будет?

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

[Антон (LogRus)]

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

[RXL]

LogRus, boost в моем случае исключен - слишком старый компилятор, да к тому же еще и Борланд. Только стандартные средства. Потом, руками оно легче контролируется, чем автоматом.

[Антон (LogRus)]

RXL, это отмазки boost прекрасно собирается для Borland
Я не настаиваю, просто привожу примеры использования RAII

ведь смотри как красиво

Код:

typedef boost::mutex mutex; // или другой boost::mutex или tbb::mutex
                                               // благо семантика одинаковая

mutex m;
void foo()
{
  mutex::scoped_lock l(m); // Lock
  ..............................
} // Unlock


void foo2()
{
  ........................................
  if ()
  {
     mutex::scoped_lock l(m); // Lock
     ........................
  } // Unlock
  ..............................
}

[Dimka]

надо написать 3 строчки кода убрав при этом 3 другие, вопрос в чём сложность?

В умножении сущностей без необходимости - бритва Оккама не позволяет Я это расцениваю как преждевременную оптимизацию. Вынос имеет смысл только при неоднократном использовании. В противном случае, чем проще - тем лучше. Обоснуй обратное.