Re: Exception specifications unfortunate, and what about their future?
on Sun Dec 21 2008, Eugene Gershnik <gershnik-AT-gmail.com> wrote:
On Dec 19, 6:16 pm, David Abrahams <d...@boostpro.com> wrote:
on Wed Dec 17 2008, Eugene Gershnik <gershnik-AT-gmail.com> wrote:
The reason I oppose static checking of exceptions at a
function granularity is precisely *because* the client of any non-empy
interface is so far removed, and separated by many many call layers of
function that have no interest in the non-empty interface.
Ok, it is a good argument (and subtly but very different from the
usual misguided complaint about having to 'fix' too many functions
when low-level one changes).
That may not be a misguided argument if you are doing cost-benefit
analysis.
However, isn't this the same for everything that uses strong typing?
For example you might have some int x. Then you carry it through all
of these func(..., int x, ...) just so that in one or two places
something will do x/2 that really cares about the fact that x is an
int. A scripting language programmer might view all of these types in
signatures as an unnecessary thing with no real benefit for functions
that only care about empty interface. How is it different?
It's different because:
* unlike ordinary return values, exceptions have an
automatically-attached control flow semantics that tends to skip over
many layers.
* Special recovery or unwinding actions (by which I mean to exclude
error reporting, logging, or translation) for individual exception
types are comparatively rare. It usually does not affect program
state if you handle all exceptions in the same way, without knowing
their individual types. Thus the practicality of destructors, RAII
objects, etc.
These are qualitative differences, not absolutes, and they impact the
cost/benefit analysis of enforced exception specifications. At the
limit, exceptions _can_ be used in a way that nullifies my arguments,
but in general they are not used that way.
Let's think about what happens when you *are* forced to derive all
exceptions from a given base class and you have statically-checked
exceptions. Then you can write throws(exception_base) and the
specification is always satisfied. It doesn't tell the client anything
interesting about the specific exception type. So in a way, those two
features cancel one another out. If I had to chose one, I'd prefer the
enforced common base because it has some obvious utility (you can rely
on the idiom above and the catch blocks all become simple).
You can abuse any type system in this way (for example by using void *
in C++ or Object in Java or C#). The fact that you can do it doesn't
by itself mean that the type system is useless.
throws(exception_base)
is as bad as
Object createSocket()
and should not be used in decent code.
Not so fast. You're missing a signature in the first case. If
Socket createSocket() throws(exception_base)
is really as bad, in your opinion, as
Object createSocket() throws(nothing)
then we have something to discuss. If that is the case, then please
tell me why.
Well not this exact one, obviously, but a quick Google search on
'vector exceptions' brings questions like
- "What are the exceptions that the vector template throws? For
example, when it runs out of memory?"
- "can I be sure, that push_back throws bad_alloc or a similar std
exception?"
In other words, "what does the documentation say?" Do you consider
that equivalent to "why doesn't the code do what the documentation
says?"
Sure. Both indicate bugs as far as the client is concerned.
Disagreed. The first indicates that the client didn't read the
documentation.
The only slight difference is that the first one indicates a
documentation bug while the second might mean a bug in code,
documentation or both. (All of this assuming the person asking had, in
fact, read docs before using code. A non-trivial assumption these
days.)
Yah.
Whether the bug is in the code or in docs it is a bug. It may cause
the programmer to write incorrect code, introduce unexpected behavior
into the final product and cause some user lots of trouble. The end
user couldn't care less what caused the program to malfunction, be it
bad docs, bad code, bad programmer or bad computer.
I disagree again. Not all behaviors -- not even all observable ones --
need to be completely specified, for software to be bug-free. I have no
problem with a library that documents that it throws bad_alloc when in
fact it throws some derived class of bad_alloc. Likewise, I have no
problem with a library that documents that it throws an unspecified
exception (when it in fact throws some actual exception type).
--
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! ]