-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
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
Surely it wouldn't be a problem to make this translator available as a free-standing class as well as a singleton instance.
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);
Really, this simple interface can satisfy 95% of my exception transporting needs. I usually just want to know if an exception was derived from X and/or what it's error text is. Provided that X is concrete I can get this without registration or changing the code that throws. Users with more sophisticated needs have the capability to register exceptions or derive them from transportable_exception. We all win? I understand that you and Dave see it as less simple to specify the exceptions at thread creation time but in my situation it's the easiest way. Our software is split into many small discreet libraries, static and shared. None of these libraries can make any assumptions about who has or hasn't registered exceptions so they're all going to have to do it every time anyway. Also, I'm almost never interested in the "type" of more than one exception so making the list isn't be a chore.
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.
I can understand not wanting to confuse the issues "how" and "whether", but for many simple cases they will be the same. On the other hand, I agree with you in doubting whether or not we really need a "whether" anyway. Brock