Re: Exception specifications unfortunate, and what about their future?
on Sun Dec 14 2008, DeMarcus <demarcus-AT-hotmail.com> wrote:
David Abrahams wrote:
on Thu Dec 11 2008, DeMarcus <demarcus-AT-hotmail.com> wrote:
To me exception specifications are used by the compiler as a consistency
check; a higher order of return values if you wish.
What do you mean by "to me...?" What compiler uses them that way?
Forgive my unclear sentence. I meant "To me exception specifications
_should_be_ used by the compiler as a consistency check...".
OK, I understand you're in favor of some form of static checking.
A factory is not part of the language but rather a user defined design
pattern that may be arbitrary complex. Of course there must be a way to
disable exception specifications for such situations.
I don't think you understand me at all. Let me try again:
A language change that required you to change this legal C++03:
Base* f();
into
Base* f() emits(Derived1, Derived2, ... DerivedN);
where the emits(...) clause enumerates all the possible dynamic types of
the expression "*f()"
is very similar to a language change that required you to change this
legal C++03:
void f();
into
void f() throws(E1, E2, E3, .. EN);
where the throws(...) clause enumerates all the possible dynamic types
of the thrown exception.
I know there are situations where a function can throw almost what so
ever, and there must be an easy way to pass such exceptions on.
That's not my point at all. My point is that, just as the immediate
caller (and its caller, and its caller's caller) generally has no use
for the knowledge of exactly which of an unbounded set of derived
classes is being returned from a factory function, so the immediate
caller of a function that can throw an exception has no use for the
knowledge of which of an unbounded set of possible exceptions is being
thrown. Knowing the possible specific exception types doesn't normally
have any impact at all on the correctness of calling code, except at the
specific point where exceptions are translated or reported, and even
then, the specific type may not matter much.
The idea that, at the end of a long chain of exceptions, one might do
the equivalent of a dynamic_cast to find out which specific exception
was thrown in order to report or translate it doesn't bother me nearly
as much as the cost of manipulating the exception specifications at all
those intermediate layers to keep them consistent.
Test: have you ever encountered a serious bug that made you say, "if
only I had statically-checked exception specifications, this would've
been avoided?" If so, I'd like to hear about it.
If we really need a way to statically check exception specifications
(other than the nothrow specification), I would suggest the
specifications be added to namespaces (or modules, if we ever get those)
and not enforced at the granularity of single functions. That's
actually a feature I might be able to support.
Already in my first post I suggested a way to pass on critical
exceptions like for instance std::bad_alloc.
Who decides if an exception is "critical?"
However, your example is a bit misleading since only the imagination
should limit the types of dynamic classes returned from a factory
meanwhile the same approach for exceptions most certainly leads to
unmaintainable code.
Assuming only the current language features, why do you assert that a
proliferation of exception types will make code unmaintainable?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]