Re: Class throwing exceptions in aggregate static initializer causes
abort() ...
* Marvin Barley:
OK, Mr. Steinbach, hate to oppose your valid argument here, but we
again have a static initialization. This static initialization uses
class _string_, which uses _new_, which _can and will_ throw exception
if system memory is too short, and there's nothing left in core memory
or swap ... (speaking in UN*X terms).
This leads back to point 1. -- core dump because of abort(): "uncaught
exception in global initializer", which is called before main.
Yes, that /possible/ (see below) allocation failure is an issue.
The most important thing to realize about memory allocation failures is
that in current desktop systems and larger they (unfortunately) almost
never occur: before any ordinary allocation fails the system typically
slows to slower than a snail's pace (because of virtual memory) and so,
unless the program tries to allocate a very large chunk of memory that
the OS can see outright must fail, the program won't get to that final
"drop" allocation that might fail (it would IMO be much better with a
strict limit on per process memory usage by default, easily configurable
on-the-fly, instead of a rubber band that's streched to infinity, and
with Java/C# the rubber band stretched via a rubber band, but no).
The second most important thing to realize is that /if/ an allocation
fails, there's almost never any cure, any reasonable way to continue
program execution. In particular, C++ standard exceptions use dynamic
allocation, and so aren't safe in this situation (this is a library
active issue, not yet resolved, and yes it's ugly, almost as ugly as
those rubber bands). The only thing you can reasonably do is log the
failure, if necessary (this might be difficult to do in a low-memory
situation), and terminate right away /instead/ of throwing an exception.
And to do that you need to install a new_handler.
Via std::set_new_handler.
In your situation you need to have your new_handler installed before
those pesky globals are initialized.
One way to do that is to have the new_handler installed by a static
object declared before the pesky ones, in the same translation unit.
Another way is to have each static object that depends on dynamic memory
allocation, call a function in the translation unit where the
new_handler is installed via a static object. And there are more ways.
Did I mention that globals are considered Evil(TM)?
With that in mind, another solution is to simply don't have them, to
instead pass around all that's needed (wherever) as arguments or object
members.
[snip]
I think compiler should have at least warned me that I throw
exceptions in static initializations, don't you?
C++ allows you to level the nearest city block just by typing the wrong
character in a line of source code; much more powerful that way than C. ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?