Re: throwable .vs. non throwable?
On Jul 25, 6:47 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1185373756.072603.20...@o61g2000hsh.googlegroups.com>,
james.ka...@gmail.com says...
On Jul 24, 8:34 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <46a63bfc.10204...@news.utanet.at>, rpbg...@yahoo.com says=
....
[...]
They just don't work as in Java.
Irrelevant -- Java's exception specifications are no better.
They're actually worse, because you can't specify the most
interesting case.
I'll take your word for it -- I've used Java exceptions enough to be
quite certain they're no better. I found them more problematic, but
hadn't used them _quite_ enough to be sure the extra problems were
really their fault rather than mine.
The problem is simple: the only really interesting guarantee is
that a function won't throw at all, and in Java, it's impossible
to write such a function. (How can you guarantee that a
function won't raise VirtualMachineError.)
The problem is really deeper than exception specifications. For
some types of errors (like VirtualMachineError, or
AssertionError), even trying to unwind the stack is dangerous.
You want to stop dead. With prejudice. The problem is that
Java refuses to recognize this.
[ ... ]
If you're trying to write exception safe code, you need some
sort of guarantee that certain functions (swap, for example,
with some common idioms) or operations don't throw.
True, but I'm not convinced that exception specifications are
a good way to accomplish that.
[ ... ]
If the contractual guarantee is that the function won't throw X,
then aborting the program if it does sounds very much like what
I'd want. It's what assert does for the (many) other checks I
write.
The difference, at least as I see it, is that assert helps you gather
information about the problem, whereas exception specifications throw
away the information that was available.
assert prints out a little bit of useful information before aborting --
but unexpected() just aborts or throws a bad_exception. bad_exception,
in turn, provides no way to retrieve information about the original
exception to help diagnose the problem.
unexpected() aborts, period. By default at least. And if I
write "throw()" after the function declaration, I am guaranteed,
no matter what, that no exception will leave the function, ever,
and that the stack will never be unwound accross the function
boundary.
After that, I've got a core dump, which should give me all the
information I need. Exactly like assert. (Note that when my
application programs run, standard error is normally connected
to /dev/null. So any message assert may output is lost. It's
the core dump which has the useful information, however.)
Even if, for example, bad_exception contained a pointer to the original
exception, the whole mechanism would become far more useful in a hurry.
The problem with that, of course, is that we don't know the type for the
pointer -- even though (nearly?) everybody agrees that exception classes
should be a monolithic hierarchy, C++ doesn't require it, so we don't
know what type that pointer should be.
The fact that you can't copy an exception of an unknown type is
a problem in general; it makes it impossible to propagate an
exception accross a join, for example. I think there will be
some evolution concerning this in the next version of the
standard. I'm not particularly worried about bad_exception,
however, because I'll never see it.
If nothing else, it could be a
void *, so you could at least cast it back to the base of the hierarchy
-- but when unexpected() is called, it doesn't receive (a pointer or
reference to) the original exception object, so we can't even do that
much.
Likewise, if unexpected() could find that the exception was (derived
from) std::exception, it could do something like:
std::cerr << original_exception->what();
to give you at least some clue of what went wrong before aborting your
program.
If these were possible and implemented, I'd agree that exception
specifications would become as useful as assert's. Without something
along that line, however, I'm left wondering how they can be considered
even roughly comparable.
An exception specification without bad_exception will not cause
bad_exception to be raised. Since the only really useful
exception specification is an empty one, which doesn't allow
bad_exception, you should never see this exception. terminate()
will be called, and the core dump will point you to the exact
line where the exception was raised, along with giving you ca
stack trace back to the function which thought it wasn't
possible.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34