RE: [Boost-users] Re: Guidelines for effective exception usage
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. It's not hard to imagine an environment where grabbing a couple extra Kb would be a Bad Thing, but I'd think this trick would be fine on PCs and the like. --Mark Storer Senior Software Engineer Verity, Inc.
"Mark Storer" <MStorer@verity.com> 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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On 8/23/04 8:33 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
"Mark Storer" <MStorer@verity.com> 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
"Daryle Walker" <darylew@hotmail.com> wrote in message news:BD536404.E6FB%darylew@hotmail.com...
On 8/23/04 8:33 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
"Mark Storer" <MStorer@verity.com> 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).
<snip>
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.
I guess you mean the exceptions from <stdexcept>. Here you're at the mecry of the library implementation. You still derive from std::exception and use whatever memory management policy you want. Jonathan
participants (1)
-
Daryle Walker -
David Abrahams -
Jonathan Turkanis -
Mark Storer