Re: Exception Specifications
On May 5, 6:45 pm, Martin York <Martin.YorkAma...@gmail.com> wrote:
On May 5, 3:06 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
The last thing (in most situations) you actually want your
application to do is terminate with extreme prejudice.
If there is a violation of the contract, that's exactly what
you want to happen. If the program is not working
correctly, it is important for it to terminate as quickly as
possible, with as much prejudice as possible, so the system
can take whatever steps are necessary in such cases.
It is only in the most exceptional cases that I want my
application to finish without tidying up after itself.
Violation of contract is a programming error. Hopefully,
programming errors are very exceptional cases in your
application. If you have a programming error (e.g. assertion
failure), something has happened that you know couldn't happen.
That means that your reasoning about the code was wrong,
somewhere. So "tidying up" isn't going to do what you thought
it would either, and is in fact likely to make things worse.
Yes I want this facility but this is the exception (no pun
intended) not the rule.
Think of "throw()" as simply "assert(won't exit by exception)".
That's really what it comes down to. In specific cases, it's a
very important part of the contract, and it's definitly worth
asserting.
If I detect an unexpected exception (ie a contract was broken)
I may want the application to finish (trying to avoid the word
terminate) but I would rather unwind the stack and make sure
all the destructor's are called so that all my resources are
nicely cleaned up and then finish the application.
But notice the key word here is (detected). We have detected
the breach in contract so there is a possibility that we could
do something about it, probably not a lot we can do but we
don't need to penalize other applications (ie your DB because
the connection is unexpectedly been severed) because our
client has misbehaved.
In real life, other applications (or other programs in the same
application) have to be able to handle an abrupt termination of
your program. Because that's the way systems work: some errors
will lead to an assertion failure, or terminate() being called;
others will cause the system to terminate the program
immediately, no questions asked.
The case of throw() is particularly special, because normally,
if you're using it, it is because not throwing is an essential
part of the contract; the stack is (temporarily) in a state
where stack walkback isn't possible. (Consider what would
happen if std::swap threw while you were swapping pointers in
the swap idiom of assignment.)
But we are talking very much in generalities here and each
situation is unique and will require its own analysis.
Yes. There are applications where it is better to stumble on,
and hopefully be able to recover something. (Games come to
mind.) I suppose a compiler with an option to turn it off (much
as you can turn off assertions) might be useful. The default,
however, should be like assertions: on (and I've never delivered
code with assertions turned off).
--
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