On 8/23/04 8:33 PM, "David Abrahams" wrote:

"Mark Storer" 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