Re: Exception specifications unfortunate, and what about their future?
Karl Uppiano wrote:
If I were writing templates, I would declare exceptions that derive
from my own exception hierarchy (could be Boost, ACE, or other,
depending on who I was), and are relevant to the semantics of _my_
problem space. If the client class throws something else, the template
would be responsible for translating it into one of my exception
types. My exception might support _nesting_ the original cause for
those who are interested. The fact that C++ allows people to throw
_anything_ makes this more difficult.
If you were writing templates, you would soon discover the true meaning
of the term "generic".
Suppose you were to write a standard-style container, i.e. a container
with copy semantics that is able to hold any type. Let's just look at a
simplified implementation of insert:
template <typename T> class my_container
{
//...
iterator insert(iterator pos, T const& item) throw (my_exception)
{
iterator new_pos = make_room(1);
try
{
*new_pos = item;
}
catch(...) // T might throw anything
{
// what goes here?
}
return new_pos;
}
//...
};
How could generic code possibly translate an exception that is specific
to T's problem domain into a generic format, and even if it could, how
could it avoid losing information? There's T-dom code on top which
understands and handles T-dom exceptions, and T-dom code at the bottom
which generates T-dom exceptions. You suggest that T-dom abandons its
specific exceptions although they make perfect sense, just because the
generic container is used in between. I don't see any sense in that.
--
Gerhard Menzl
Non-spammers may respond to my email address, which is composed of my
full name, separated by a dot, followed by at, followed by "fwz",
followed by a dot, followed by "aero".
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]