$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-02-12 16:25:08
Brock Peabody wrote:
>
> That's true. I'm still a little uncomfortable with the idea of a
> static register though. How, for instance, would you share a
> register between dynamic link libraries if the register is static?
I may or may not be right, but I don't expect this problem to occur
frequently in practice, if the recommendation is to use
throw_transportable_exception, with register_ only being used when it is not
possible to modify the throw statement.
The architecture I'm picturing in my mind differs slightly from your
implementation (and probably Sam's, I haven't had time to look at it). I
envisage a (reusable, perhaps) exception translator that catches all
registered and standard exceptions, wraps them in a new shiny
transportable_exception package, and rethrows, something like
template<class F> void translate_exceptions(F f)
{
try
{
f();
}
catch(transportable_exception const &)
{
throw;
}
catch(registered_exception_1 const & e)
{
throw_transportable_exception(e);
}
// and so on
}
with the optional< variant<R, ...> > of your implementation replaced by an
optional<R>, auto_ptr<transportable_exception> pair.
The unfortunate author of a DLL that calls sourceless throwing functions but
needs to register_ exceptions can just wrap the functions in his own
exception translator, if all else fails. We may even provide a generator
exception_translator_generator<X1, X2, ..., Xn>::translate(f);
>>> If there is an excepted exception list, do you think it makes sense
>>> to have the library automatically register the types in this list?
>>
>> Possibly, but I'm not sure how useful that would be. I'd usually
>> only put abstract base classes in that list. :-)
>
> Now I'm confused again :) My understanding was that there is no way
> to transport a user defined abstract base class unless you derive it
> from transportable_exception, in which case it wouldn't need to be
> registered at all.
I'm just saying that I'd probably use the expected list strictly as a
"whether" mechanism, as I'd prefer to specify the "how" only once, not per
thread creation point. But that's just my opinion.