Здравствуйте, Андрей Галюзин, Вы писали:
АГ>А, по-моему, вкус здесь не причём.
АГ>Простой и глупый пример:
АГ>АГ>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(...), то деструктор второго объекта не вызывается.