Re: We do not use C++ exceptions
"Jeff Schwab" <jeff@schwabcenter.com> Hardware (including lifejackets) and
software (including exceptions) are
no different in this sense. The presence of a life jacket proves that
someone foresaw the potential need for it. The same is true of a
throw-expression.
We don't give people life jackets in the hope that the bearers will
somehow innovate their way out of watery deaths. We hope that they
might be rescued. Sometimes this works, and sometimes it doesn't.
But lifejackets do not cause danger of their own, while a C++ software
getting in an unforseen situation CAN be.
Similarly, even crippled software can still be useful, if only to
support interactive debugging.
We here are talking about live systems used by users. For real tasks like
processing money on a bank account, receptor data in system control, etc.
Interactive debugging is out of question.
Just as a sick patient has a far greater
chance of recovery than a dead one,
So does he more chance to spread smallpox or ebola is left walking.
an ailing application beats the heck
out of a core dump. Debugging a core dump is the software equivalent of
an autopsy. Once a program dies, the most you can hope for is to learn
enough from the death to avoid similar problems in the future.
Err, assert failure dumps core alright (or can be made so). If you throw
exception you destroy the environment by unwinding the stack and walking up
to a far "handler". That may even let the program go ahead. What more you
learn from that?
When the Remote Agent software on Deep Space 1 detected an internal
inconsistency, the engineers on the ground were able to debug the cause
(a race condition), and salvage the mission. Had the original
programmers chosen to terminate the application, rather than entering an
interactive debugger, the $100M mission might have been a complete loss.
This supports our point -- they did not let the program proceed.
You seem to misunderstand or flex the terms we are using.
1. "unexpected". That supposed to mean condition the design said will not
happen.
The cases where exceptions are thrown are "expected", and included in the
defined behavior of the function. Sure, there are such
funcitons/situations, we're talking about the *rest*.
2. "terminate immediately" means the normal execution in the original
environment does not continue. It can still mean doing other safe
actions -- i.e hibernate the process, using assembly to call some OS
functions, flip I/O ports, switch to another VM, etc.
The opinion some people express, when pressed, is that somehow
they don't really mean the whole system should die, only the
misbehaving portion.
Sure, we don't want annihilate Earth or start a new big bang. :) The
problem is that in a C/C++ system there is too little chance to isolate a
misbehaving part. The baseline is to think the process being the the unit
to kill on a unix/win32-like system with process separation. If you could
create a true sandbox that is smaller, sure, go ahead with the rest.
I'm guessing most of those people have never done
defense work, nor embedded systems development, nor even Unix device
drivers.
I'm quite sure most people who contributed to this thread did average 2+
decades high-demand work, including in those very environments or close
analogs and more.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]