|
Boost : |
From: Jeremy Day (jeremy.day_at_[hidden])
Date: 2006-08-08 17:03:21
Gentlemen,
I just want to start by saying thanks for the comments. I'm wrapping my
brain around some of it, and hopefully I'll have time to work on this again
very soon.
On 8/8/06, Alexander Nasonov <alnsn_at_[hidden]> wrote:
> So, this library should a simple utility library that doesn't rethow if
> possible and doesn't hide a lot from a user.
I will do some research into using preprocessor metaprogramming to remove
the rethrow, or at least provide a macro that does that.
1. Catch a list of exceptions in one line:
>
> try {
> throw std::logic_error("testing");
> } BOOST_CATCH_PP_SEQ((ex1)(ex2)(ex3), my_exception_handler());
>
> There is no need for MPL counterpart because you can always transform PP
> sequence into MPL sequence (but this functionaly seems to be missing in
> boost). If you can't do that (e.g. you need to mpl::push_back, or apply
> mpl::transform_view), then this library goes beyond a simple utility ;-)
>
> 2. Catch and dispatch (or visit, if you like)
>
> try {
> throw std::logic_error("testing");
> } BOOST_CATCH_AND_DISPATCH(std::exception&, my_exception_handler());
>
> This code rethows but it doesn't catch(...) but rather
> catch(std::exception&).
>
> Needless to say that my_exception_handler should be as simple as
> possible. Macros inside this class should be avoided because it's often
> impossible to go to a definition of a function inside it.
>
> Currently, my_exception_handler in item 1 has different (and much
> simpler) interface compared to that from item 2. It would be nice
> to have common interface.
I personally think that item 2 has the easier interface. I will definitely
work on a macro where you can specify what to catch, in lieu of always
catching ... . Furthermore, I really like using the MPL sequence, because I
found that it is very easy to order the exceptions so that you don't
accidentally have catch(std::exception&) before you catch a derived
exception, such as std::logic_error.
Jeremy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk