Re: [Boost-users] Guidelines for effective exception usage

From: Daryle Walker (darylew_at_[hidden])
Date: 2004-08-26 08:55:16

On 8/23/04 8:33 PM, "David Abrahams" <dave_at_[hidden]> wrote:

> "Mark Storer" <MStorer_at_[hidden]> writes:
> 
>>> No it is not.  Even if you aren't throwing due to memory starvation,
>>> you could run out of memory during unwinding, when the exception is
>>> copied.  That leads you directly to terminate().  Do not pass Go; do
>>> not collect $200.
>> 
>> Venturing a little far afield, but one technique I've heard of is to
>> grab a block, so you can release it in low-memory situations (or just
>> every time you throw).  This ensures (in theory) that you'll have
>> enough memory to copy your exception, create your strings, and so on.
>> If you manage to recover, you just grab another block ("prime the
>> pump") and soldier bravely forward.
>> 
>> Given STL's habit of allowing people to specify an allocator, you
>> could even go so far as to build a custom allocator that worked on
>> some pre-allocated block of memory for your exceptions (strings,
>> vectors, whatever you deem necessary).
>> 
>> Either way, you'll run out of memory a little earlier (not a big issue
>> in many environments), but you _will_ get to pocket the $200.
> 
> Maybe.  You can still exhaust your pre-allocated buffer.  There's no
> need to play with fire here; it doesn't buy you much and it's easy to
> avoid.

The pre-allocated buffer via a custom allocator won't help.  The standard
exception classes take standard strings as constructor arguments.  You can't
change the memory policy for those classes, so you may end up with an
out-of-memory second exception if the standard memory pool fails.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com