Re: Exception specifications unfortunate, and what about their future?
On Nov 21, 2:46 pm, Pavel Minaev <int...@gmail.com> wrote:
I disagree. C++ exception specification can be statically checked in
exactly the same way as function types are checked - since they are
(or should be) available on declarations of functions in the header,
the compiler has them available at all times. There is no requirement
for "reflection" or other similar runtime type metadata provider to
implement checked exceptions.
The compiler certainly does not have every header in a system
available at all times, nor should it. Most well factored libraries
will use so-called private headers, and these signatures are not
available (by design) to the client code.
Lets see what happens:
In a cpp. file, we include headers for three libraries that do the
same thing. This generates a binary for a dynamic link library. So not
only the compiler does not know, but the linker as well does not know
at build time. We only find out at runtime:
#include <liba.h>
#include <libb.h>
#include <libc.h>
void mywrapper(T arg){
if(use_liba)
liba::process(arg)//may throw a liba:exception
else if(use_libb)
libb::process(arg)//may throw a libb:Exception
else
libc::process(arg)//may throw a libc:error
//of course, we are also using std::, which can throw std::exception
}
(for a real world example of this sort of thing, look at the QuickFix
library, which uses exception specification + multiple XML parsers. )
The header has no knowledge of the three libraries:
void mywrapper(T arg);
The exception specification in the header declaration either:
1. Has to list every exception thrown by each library, which breaks
encapsulation, which is the entire point of mywrapper
2. Implement mywrapper to catch every possible exception, and convert
it to a type to match the exception spec. This is extremely tedious
and error prone ? if you don?t get it right, BOOM your app terminates
by default. No one want to use mywrapper then.
3. let mywrapper emit any exception, and let the catch point deal with
it.
None of the above is particularly appealing, however, after much trial
and error number three is the most workable. Encapsulation is not
broken if catch(?) is used, there are no tedious exception conversion
routines, and the exception is handled at place designed to deal with
exceptions.
Of course, the client is probably catching using catch(?) which
trashes some hopefully useful diagnostic info. But the system is still
correct, reliable, and encapsulated. If that diagnostic info is
needed, well, then something has to give, but exception specs don?t
help with this.
I really thought they did at one point, and used them religiously,
until they themselves became the major source of system unreliability.
In any case, and A Marlow points out, what if mywrapper were a
template? Such that
template <class A>void mywrapper(T arg){
A::process(arg);
}
There is no possible way for the template author to provide mywrapper
with an exception specification. For static checking to work, the
compiler would have to keep up with the exception spec used for process
(), and somehow the template ?inherits? this spec. Not too hard for my
one line example, but consider
template <class A, class B, class C, class D >void mywrapper(T arg){
D::foo(C::bar(arg?B::tricky():A::process(arg)));
}
I suppose that mywrapper could automatically spec the union of the
unholy mess of exception specs, however, there is no programmer who is
ever going to write catch blocks for each case and get it right, even
if they could get info on what the generated exception spec is.
To drive this home, one thing that C++ has that Java does not, is
operator overloading. They can throw as well. Sigh. Or something like
streams, where you can turn exceptions on and off, and indeed, through
some trickery, throw them at a later time. How would a static spec
handle that?
2. Java exceptions are used as diagnostic tools primarily, to be used
in conjunction with the stack trace. The recoverability is a secondary
role. C++ exceptions are used primarily as system recoverability
mechanism, to be use in conjunction with the destructor. Their
diagnostic features are very limited. A good C++ program will operate
correctly without ever knowing the type of exception thrown. In Java
this is much more difficult.
The perspective can be viewed this way: Java exceptions are concerned
with detecting violations in function preconditions, while C++
exceptions are concerned with protecting class invariants. (this is
why the isValid() functions in C++ libraries are considered bad
form).
I will disagree here as well. For one thing, C++ exceptions can and
are used to signal violations of preconditions - in fact, quite a few
standard library exceptions are specifically dedicated to this
(std::invalid_argument, std::out_of_range, std::domain_error,
std::range_error etc). For another, good Java code will also use
exceptions to protect class invariants in the same way as C++ code
does (and default public constructor paired with some form of
initialize() and isValid() is similarly frowned upon).
They can be used that way, sure. I have seen programmers use them to
make ?typed goto? statements
try{
if(something)throw 1:
throw 1.0;
catch(int){
}catch(float){}
And yes the standard library uses them to signal precondition
violations. The point was that debugging a program that uses C++
exceptions to protect preconditions is very difficult. (The MSVC
debugger does an excellent job in this regard though). The Java
exceptions seemed esp designed to provide stack traces, making them
far easier to use in spotting precondition violations.
Also realize that much of the standard library was designed when there
were very few compilers that actually supported exceptions. The same
story applies for things like member templates, partial specialization
and the like. Around this same time (mid 1990?s) there was much
concern that it was impossible to actually design exception-safe
templates. This of course was proven wrong, but the standard libs were
finalized not long after that.
There was a natural tendency to replace the standard C library return
codes with exception types (which is why we have exceptions of those
types) and use them for preconditions just like they were used in the
C library. However, exceptions are not generalization of return code,
but rather generalizations of longjmp. When people start thinking that
C++ exceptions == return codes, then they are bound to be
disappointed. Java takes the ?exception is a generalized return code?
point of view however, and adds in support, as you say, for long
distance jumps.
Also, I do not see how destructors enter into this picture. Java
finally-blocks play a similar role WRT exceptions and RAII, they just
take more effort to implement and maintain.
What finally block does is force the programmer to be conscious of
exactly the path taken from the try to the possible throw point, so
that if something needs a finally (like freeing a lock) then this case
is handled. There are even code samples in the Herlihy book that screw
this up.
This makes it particularly difficult to refactor code. Note, however,
that the plethora of tools available to a Java programmer for this
purpose far outweigh the difficulties imposed by finally blocks.
This really boils down to the fact that C++ and Java exceptions are,
indeed, the same thing: a non-recoverable dynamic nonlocal transfer of
control mechanism.
So if it is considered bad form to rely on the type of exception
thrown
It is? You mean, it is frowned upon catching ios_base::failure from
fstream constructors?
If you are relying on it for program correctness, then yes. If you are
using the type for diagnostic purposes then no, so for example
try{
ifstream f;
f.exceptions ( ifstream::eofbit | ifstream::failbit |
ifstream::badbit );
f.open(?something?);
//use f;
}catch(ios_base::failure const&e){
std::cerr<<?Oops!! Failed in fstream around ?<<__LINE__;
//throw;//should be commented in for correct operation
//OR also use a catch(?) block to handle all other exception
types
}
//more code either called for all cases i..e catch(?) is used, or for
//only nothrow cases, i.e.. throw; is used
In this case I personally prefer
ifstream f;
f.open(?something?);
if(!f)throw std::runtime_error(?could not open \?something\??):
//typically in a macro that also gives me __FILE__ and __LINE__ info
Now I am not trying to fool around with various catch blocks. I
perhaps have two or three such blocks for an entire application. God
forbid if these were finally statements.
Lance
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]