A newbie should definitely let the program abort,
Probably. (If the newbie is working in a larger team, he should
use whatever mechanisms the team has established. But setting
up a framework to do anything but abort isn't a task for a
newbie.)
Running out of memory just happens to be a convenient example.
More generally, of course, you have a complete hierarchy of ways
to handle errors, from aborting, to simply noting the error and
continuing in a degraded mode (something like ostream, for
example). Which one to use will depend on the type of error and
the application constraits. There is no universally "right"
solution. Which is really what lies at the heart of the
original question: if you're writing a generic class, for use in
many different applications, what do you do? The most useful
solution is generally to use the least radical solution which
could reasonably apply. In the case of out of memory, it's hard
to imagine anything less that an exception as being acceptable,
although I agree that at least 90% of the time (newbie or not),
aborting is what is really required. But from the user's point
of view, it's easier to convert an exception into an
abort---just don't catch it
---than it is to convert an abort
into an exception.
in the case of memory exhaustion via a new-handler
(set_new_handler or whatever the name was), because with basic
resource depletion higher level code won't be able to do
anything and will most likely fail in turn: even the throwing
of a standard exception might fail...
Formally, just about anything might fail at any time. The
standard has a cop out saying that not enough resources is
undefined behavior. Of course, we all count on quality of
implementation as well. On the systems I use, you can catch
bad_alloc and continue (although you may have to configure the
OS correctly in order for the error to be detected). On the
systems I use, there are even ways of guaranteeing that the
stack doesn't overflow (but they're very system dependent).
It is perhaps ironic that I have argued the position of using
exception, e.g. with Dave Abrahams (who then took the position
I'm doing here, that of terminating at once). But that was in
the context of very advanced error handling, of possibly
cleaning up some things and doing a Bird Of Phoenix: error
handling for newbies and ordinary error handling is something
else.
It all depends on the application. I write large scale server
software. My programs run on dedicated machines, with
sufficient memory. Most of the time, if I run out of memory,
the only possible reason could be a memory leak. In that case,
it's definitly best to abort and restart the application; the
situation won't get any better otherwise. But there are
exceptions: consider a protocol like LDAP, where the client can
send arbitrary "expressions", which will typically be
represented internally in the form of an expression graph.
Regardless of how much memory you have, expressions which
require more can exist. In such case, catching bad_alloc and
responding with an "insufficient resources" error is a very
viable solution. (If you've programmed correctly, the stack
walkback of the exception will ensure that all of the nodes are
released.)
That's good advice, but the advice about choosing exceptions
or not based on how "exceptional" the situation is IMO ungood
advice -- no matter that it is advice that's (mindlessly,
and with reference to some "authority") repeated by a majority
of C++ programmers.
In addition to being so vague and subjective as to be
worthless, it's worthless because what can be "exceptional" in
one context need not be exceptional in some other context.
It's vague and subjective precisely because it depends on the
context. No one is claiming anything else. It's a sort of way
of saying that it depends, with a very vague suggestion about
what might be relevant to consider.
Instead, use exceptions where they provide clarity and are
most practical -- same advice as for use of loop constructs
and other language constructs.
OK. I'm not sure what "most practical" really means in this
context, but clarity is certainly important. Of course, which
solution is clearest will also depend on the application:
"provides clarity and are most pratical" is also vague and
subjective.
Which is fine, because the issue is vague and subjective; since
the correct answer depends a lot on context, any context free
answer must be vague and subjective.
