Alexander Nasonov wrote:
try { throw std::logic_error("testing"); } BOOST_CATCH(my_exception_handler());
I'd changed BOOST_CATCH to something less generic.
Why? boost doesn't have such a macro till now. For me it means that there was no need in such a generic facility and it can be concluded that a chance for name clash in future is only theoretical here. From other point actual meaning of this macro is "catch and handle" but BOOST_CATCH_AND_HANDLE is too verbose for me. I believe that BOOST_CATCH is good enough. It is a compromise between user-friendliness and brevity. Fill free to suggest something if you are not convinced yet.
try { throw std::logic_error("testing"); } BOOST_CATCH_EX(exceptions, my_exception_handler());
Well, if it's macro, why not just generate handle-seq (a list of catch clauses) rather then catch(...) { handle(); throw; } ?
For example:
try { throw std::logic_error("testing"); } BOOST_CATCH_PP_SEQ((ex1)(ex2)(ex3), my_exception_handler());
You could even pass mpl sequence to a macro if you know a size of the sequence:
try { throw std::logic_error("testing"); } BOOST_CATCH_MPL_SEQ(3, mpl::vector<ex1,ex2,ex3>, func);
This could be expanded to
try { throw std::logic_error("testing"); } catch(mpl::at<mpl::vector<ex1,ex2,ex3>,0>::type const& ex) { BOOST_STATIC_ASSERT(( 3 == mpl::size<mpl::vector<ex1,ex2,ex3> >::type::value)); func(ex); } catch(mpl::at<mpl::vector<ex1,ex2,ex3>,1>::type const& ex) { func(ex); } catch(mpl::at<mpl::vector<ex1,ex2,ex3>,2>::type const& ex) { func(ex); }
Interesting, but complicates usage. Note that in BOOST_CATCH macro exceptions_handler() defines typedef ... exceptions; but in you version of BOOST_CATCH_EX macro it is defined as a PP sequence. Why two ways to do the same thing? There should be a very good reason to add such a functionality. Yes, only add, not replace current. average user like me ;-) should be isolated from PP sequences. They are good for library internals, not for interface IMO. Alexander Nasonov wrote:
Two reasons why I would consider PP version:
1. catch(...) followed by rethrow might be less efficient than
handle-seq. I never measured this, though. boost::filesystem has two versions of all functions that could generate exceptions. reason is clear - in performance critical applications one can not use exception machinery because the cost of stack unwinding is not acceptable. My contra-point here is that one shouldn't use exceptions if performance is too important for this particular piece of code.
2. catch(...) catches too many things on some compilers. I know only one (very popular) compiler that also catches system exceptions (aka SEH). Though, I don't remember how it rethrows those exceptions.
Seems that we are both not very knowledgeable in this area. I remember that SEH handling is done in boost::test library. So, maybe Gennadiy Rozental can shed some light here? Best, Oleg Abrosimov.