Re: Exception specifications unfortunate, and what about their future?
on Tue Dec 16 2008, DeMarcus <demarcus-AT-hotmail.com> wrote:
David Abrahams wrote:
OK, I understand you're in favor of some form of static checking.
Yes, I would like to be able to check at least some exceptions in compile-time.
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.
I totally agree with you that there is intermediate code that has no use of knowing
about exceptions thrown through them. The best example is template
containers.
I disagree, in the sense that the issue is just as compelling in
non-templated code.
That pass-on problem is something that has to be solved in a way
satisfying both pro- and con- static exception programmers. (see more
below).
That's news to me.
Still I would like to try answer your factory example to see if I
understood it. If you return an instance from a factory of type Base*
and has declared for instance Base::calculatePI() throw (OutOfControl)
then that would mean that the programmer tells everyone implementing
Base that it is very important that OutOfControl is there.
Still missing the point, I think. The Base/Derived example is supposed
to be an analogous scenario that *doesn't* use exceptions, to make the
same point about the maintainability of code.
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.
First of all; those are the bugs you never want to encounter
Of course. Aside: what kind of bugs *do* you want to encounter?
since they will show up as an angry mail from your customer.
And yes, I have encountered such bugs during some Java projects. The
problem with static checking in Java is very good described in the
Bruce Eckel article provided by Marlow Andrew in this thread.
http://www.mindview.net/Etc/Discussions/CheckedExceptions
In that project I had an exception I thought "It never come that
often, and I don't really know how to handle it right now", and then I
swallowed it (described in the article). However, that swallowing at
least allowed me to log the bug and do a graceful shutdown so I had a
chance to go back to the code and think that problem through. And the
best of all; it puts a pressure on me as a programmer that I'm sloppy
here swallowing exceptions. I then know I'm doing something bad and
put the problem on my todo list.
It sounds like you're telling me that you deliberately introduced a bug.
The compiler told you an exception would be thrown and instead of
propagating it when you didn't know what to do, you swallowed and logged
it. If the compiler hadn't alerted you to the exception, you wouldn't
have swallowed it.
My claim is that not swallowing the exception would have led to a
program that was no less correct than the one that swallowed it, and
quite possibly more correct. If that's not the case, I claim this is a
highly anomalous example, because it's exceedingly rare that recovery
actions must differ based on the type of exception thrown.
As another answer to your question I will mention a similar argument
as Eugene Gershnik wrote in this thread; that the exception
specifications help you check whether you follow the documentation.
Yes they do, but at what cost? My claim isn't that they have no
benefits. It's that the costs so outweigh the benefits as to be
insignificant.
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?"
That's also a good point. When it comes to for instance the STL there
may be a lot of opinions here. Nevertheless, at least for me there is
at least a distinction between error exceptions and problem exceptions
where errors are show stoppers and problems should be expected in an
application, caught and handled appropriately. Preferably with the
compiler to your help.
Show stoppers represent programmer errors and should almost never be
handled with exceptions for reasons I've detailed many times over the
years (search the archives here).
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?
I meant that the framework should be programmed in a way so you easy
can add whatever module you want whenever you want. But adding
exceptions demands a careful mind.
I'm sorry, I can't see what you're driving at. Please be specific.
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.
Again, in Eckel's article there is a quote in the end from a C#
language designer where he or she points out that exception
specifications are good under certain circumstances.
How does that address what I wrote above? It seems as though you're not
even reading it.
As a matter of fact, I believe that the exception specification
situation has a lot of potential to be solved in a really professional
way. Why? Because nobody likes ES as they are designed today. The
group against ES recommend us to avoid them and the group pro ES wants
to change them. So if we can come up with a new exception
specification proposal that pleases both camps then we have actually
improved the language a lot.
Only if the feature actually works in practice. There can be a great
difference between that and what people can agree to like without having
tried it.
During this thread there have been some solution suggestions from
people pro ES. My suggestion is that everyone against ES turn their
mind upside down,
My suggestion is that you stop thinking of people as being anti-ES.
try to think as a pro ES and come up with a suggestion what ES should
look like to not affect the programmers that don't want to use them,
or maybe use them differently.
So, you're givin no consideration to the suggestion I made above?
--
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! ]