Re[4]: OFFTOP: Re[7]: "Крик души"
От: GUID Россия  
Дата: 10.11.03 16:14
Оценка:
Здравствуйте, Андрей Галюзин, Вы писали:


АГ>А, по-моему, вкус здесь не причём.

АГ>Простой и глупый пример:
АГ>
АГ>template <typename T>
АГ>void some_function(const T& original)
АГ>{
АГ>  try
АГ>  {
АГ>    T copy = original;
АГ>    // other work
АГ>  }
АГ>  catch (...)
АГ>  {
АГ>    // cleanup
АГ>    throw;
АГ>  }
АГ>}
АГ>


АГ>Чем бы ты в данном случае заменил catch(...)?

АГ>На каком основании?

Смотря что такое cleanup?
Если простая подчистка ресурсов так используйте смарт-поинтеры, классы-стражи, функторы и тп, которые в деструкторе все сделают. ( Их можно передавать и темплейтным параметром)
Если это какой-то частный роллбэк только и только в случаях ошибки, я бы не стал это запихивать в темплейтную функцию и пересмотрел бы дизайн решения.
Можно и в этом случае кстати попробовать предать какой-то функтор.

Самое плохое в единичном catch (...) — это глотание ошибки.
1)
а)Глотать _свои_ ошибки с моей точки зрения очень и очень плохо.
Я там видел в ветке народ предлагает для релиза ставить catch(...), так вот пусть лучше она упадет и создаст Dr.Watson log. чем
выдаст "Unknown error" и тем самым похоронит что там за ошибка была и почему.
Конечно, если речь идет о разовом заказе, можно отладить у клиента на его конфигурации и забыть про проект,
а если выпускать серийный продукт то каждый AV должен быть "радостью" для девелопера, так как позволяет улучшить продукт.

б) catch (...) ловит также и "аппаратные" исключения.

2) Глотать _чужие_ ошибки тоже не нужно. Часто такие catch(...) вызваны не просто ошибкой, а каким серьезным сбоем, могут быть утечки, порча памяти и т.п. Зачем все это богатство в своем процессе, если можно сделать внепроцессный компонент и шатдаунить процесс когда пошло что-то не так.

Но вариант с последующим throw и не глотает ошибки. Там есть throw.
Мы же отказались и от именно этого варианта в свое время из-за багофичи(асинхронных исключений) в VC 6.0 SP5 по причине которой в случаях, если определяется например два экземпляра объекта во внешней функции по отношению к исполняемой и происходит не-C++ исключение в catch(...), то деструктор второго объекта не вызывается.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.