Re: Is there any standard/guarantees for exception safety in STL operations?
Thomas Richter wrote:
Bo Persson wrote:
"Unless otherwise specified (see 23.2.1.3 and 23.2.4.3) all
container types defined in this clause meet the following
additional requirements:
?? if an exception is thrown by an insert() function while
inserting a single element, that function has no effects.
... and what if we are inserting more than one element? what
effect(s) we are going to have?
Bad probably. :-)
You could also read this as a hint to not insert multiple obejcts
at once, if they are likely to throw exceptions.
This statement looks very irritating to me. What means "likely"? Is
proper programming a matter of probability?
Yes, sometimes. :-)
You, as the one writning the possibly throwing copy constructor of a
class, could know when the exception might occur. The library author
cannot.
If you insert 10 small elements into a std::vector, and have 100 GB of
virtual memory available, a std::bad_alloc is not "likely". You can
ask yourself, under what conditions will an exception occur? Do we
have these conditions right now?
Can we run out of memory? Disk space? Network connections? File
handles?
As an application programmer, you might know that there are plenty
of resources available so your classes will not throw right now.
??? How should I know how many resources are available?
It depends on what resorces the stored objects require. If you write
the classes, you know that but the library author does not.
The lack of
any strong guarantee more or less means that proper handling of
resource exhaustion is impossible if you insert more than one
element at once. IOW, all I can do then is to terminate the
program? Now, for *that* I don't need exceptions, do I?
One way to get the strong guarantee is to say that copy constructors
and assignment cannot throw. But that limits the usefulness of the
library.
Another way to get a strong guarantee is to make a copy of the
container, attempt the inserts and, if successful, swap it with the
original. That would be costly, of course, and increase the risk of
getting a bad_alloc.
Still another way is to insert your objects one at a time. That either
works, or not, leaving the contairner in a known state.
Similar to the OP, I find it very irritating that at one hand
education in C++ stresses proper exception handling and exception
safety so much, while at the other hand the STL provides you with
so little to really *write* exception safe code when using it. That
is, code with
*guaranteed* behavior in case of exceptions. Basically, doesn't that
mean that one should stay away from the STL when writing code that
can *truely* handle exceptions correctly, instead of just "hoping
the best", i.e. an optimistic approach as you seem to suggest?
The library provides you with a lot of tools, but it just cannot help
you with everything for free. If you have a class that throws
exceptions randomly, that isn't very useful.
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]