Re: throwable .vs. non throwable?
On Jul 27, 4:06 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1185460494.535789.201...@r34g2000hsd.googlegroups.com>,
james.ka...@gmail.com says...
[ ... ]
unexpected() aborts, period. By default at least.
I suppose that depends on what you mean by default -- if the exception
specification in question includes bad_exception, the stock version
(i.e. not as a result of set_unexpected) can/will throw objects of type
bad_exception. Of course, as long as you only write empty exception
specifications, that can't happen...
Are you sure? I'm looking at the lastest draft of the standard
(but I don't think anything has changed here), and for
unexpected_handler, it says: "Default behavior: The
implementation's default unexpected_handler calls terminate()."
It's only if a user defined unexpected_handler throws an
exception that bad_exception comes into play.
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.
Quite true.
After that, I've got a core dump, which should give me all the
information I need.
At least you hope so.
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.)
I, for one, find the information supplied by the assert useful.
It can be useful. It's very useful in my unit tests, for
example. If you're implementation of std::vector<>::operator[]
asserts, however, I'm not sure that the message will be very
useful. My experience is that in large applications, the assert
is usually in a function which has been called with the wrong
arguments, and you still have to determine who called it.
Yes,
there are times it can be/is discarded, but at least to me there's a big
difference between deciding that it's reasonable to discard information
for your specific application(s), and deciding at the language level
that all such information must be discarded for all possible
applications.
At least on my systems, calling unexpected doesn't discard any
information. It just doesn't output anything on standard error.
The stack has not been unwound, and the critial information is
there in the core dump (at least most of it, most of the time).
Probably, an assert instead of the throw would be even more
useful. But if the code is wrong, the core dump from unexpected
is better than nothing.
[ ... ]
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.
I can't agree -- if you're seeing an exception raised that shouldn't be,
I think (a modified version of) bad_exception would be a useful way to
help diagnose the problem.
How? If you catch it, the stack has been unwound, so you don't
know where you were. And you've probably violated some pretty
important invariants. If you don't catch it, then you get a
core dump. In which the stack may have been unwound (although
as a QoI issue, I would expect it not to have been).
That's with the current situation, of course. If it were
somehow possible to obtain information about the original
exception, it might be more useful. But I still prefer a core
dump.
--
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