|
Boost : |
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-09-30 17:17:27
On 9/30/07, Sebastian Redl <sebastian.redl_at_[hidden]> wrote:
> Dean Michael Berris wrote:
> > Hi Emil!
> >
> >
> > Far from it. I'm thinking get_error_info(T const &) should not compile
> > if the error_info being requested has not been passed to the
> > exception. This would only be possible if the exception type itself is
> > composed using expression templates and its type information is
> > somehow reflected during runtime -- or it might be impossible given
> > that the exception is referred to via an abstract base `boost::error`.
> > Maybe an encapsulated tuple that "grows" along the exception
> > propagation might work though I'm not entirely sure about that as
> > well.
> >
> This is completely impossible. Full static type information would have
> to be available in order to compose a new data item into an existing
> exception, which means that a site which just wants to add information
> would have to catch the exception by its _full expression template
> type_. Given that a site might not even _know_ what exceptions might
> pass through it (if it's passed a Boost.Function object and calls it,
> for example), that's not even possible, not to mention that it would be
> completely unusuable if it _were_ possible.
>
This confirms my suspicions. Sorry for the mental fart earlier.
So while I was not 100% sure it was impossible, now with this
explanation I'm convinced it's impossible.
That doesn't take away the feasibility of an expression template in
constructing an exception that
1) doesn't require the use of shared_ptr<>'s to store additional
tagged information
2) derives from a single base `boost::exception` and
3) returns a Boost.Optional value instead of a const data * to the
value associated with an exception_info tag.
Right?
-- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis_at_[hidden]] [+63 928 7291459] [+1 408 4049523]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk