Exception checking memory allocation. How?

[Jacob]

It is common practice (I've heard) to always catch
allocation exceptions from "new". How is done in
practice? What would be a common procedure (path of
sequence) after such an event has occured? (For a
multi-million LOC, GUI based application).

It is also a common advice not to allocate objects
with "new" unless absolutely required. The alternative
is to keep objects on the stack, automatically allocated
and deallocated by scope control. Which mechanisms do
I use in order to prevent allocation errors (i.e. stack
overflow) in this case?

Thanks!

[Julián Albo]

Jacob wrote:

somehow. Following my company guidelines inter-library exception
throw/catch is not an option, so I need to use other mechanisms.

But wasn't you who were deciding the guidelines?

--
Salu2

[Jacob]

Julián Albo wrote:

somehow. Following my company guidelines inter-library exception
throw/catch is not an option, so I need to use other mechanisms.

But wasn't you who were deciding the guidelines?

Yes. And according to C++ best practices, inter-library
exceptions is not adviced.

[Julián Albo]

Jacob wrote:

somehow. Following my company guidelines inter-library exception
throw/catch is not an option, so I need to use other mechanisms.

But wasn't you who were deciding the guidelines?

Yes. And according to C++ best practices, inter-library
exceptions is not adviced.

Is "C++ best practices" the name of your company, then?

--
Salu2

[Tobias Blomkvist]

Jacob sade:

You just encouter a memory allocation failure, but the program
should be able to continue.

What if the memory allocation failure isn't just a single event,
but a complete process memory failure, what are your options then?
Can your application react and save necessary, perhaps crucial, data
without the need for more heap memory?

My experience is that most programs just crash with a curious message,
sometimes generated from the dark depths of the code structure,
hence my first answer. Memory allocation control is a rare thing.

Tobias
--
IMPORTANT: The contents of this email and attachments are confidential
and may be subject to legal privilege and/or protected by copyright.
Copying or communicating any part of it to others is prohibited and may
be unlawful.

[Jacob]

Tobias Blomkvist wrote:

My experience is that most programs just crash with a curious message,
sometimes generated from the dark depths of the code structure,

Commonly known as bad design.

Note that I am not talking about memory errors (which are bugs),
but rather resource limitation (which are predictable and can be
accounted for).

Industry level (Microsoft not included) software must check
the result of *every* memory allocation made and act appropriately
for every possible outcome; Again: Crashing is not an option!

This is not really hard. It is more like a pattern. And I like
advice on common practice.

But maybe weekends are a bad time... :-)

[Tobias Blomkvist]

Jacob sade:

Note that I am not talking about memory errors (which are bugs),
but rather resource limitation (which are predictable and can be
accounted for).
I wasn't speaking of bugs introduced by you as a programmer in your
own code.

If your system suddenly works against you, changes in resource
limitations could wreak havoc concerning memory and resource needs.

Unless you're designing the entire execution environment, somebody
else debugs a system which you rely on, and many systems can fault.

Industry level (Microsoft not included) software must check
the result of *every* memory allocation made and act appropriately
for every possible outcome; Again: Crashing is not an option!
Yes, how would you otherwise come to the conclusion that further
memory allocations might be impossible and that the severe failure
in memory allocations might raise the need of a controlled restart,
the question is just how clean you can do it, and what help your
system can give you? Restart(either process restart or context restart),
not crash. This is yet a reason why gui and core(s) should be separated
so individual restarts can be done.
This is not really hard. It is more like a pattern. And I like
advice on common practice.
Like isolating functionality to control memory mishaps. If a memory
failure (or any failure which is not related to your coding skills)
occurs in context C then terminate C (and retry). This means a design
where arguments to C will not be changed. Allocate everything within
C from a memory "pool" outside C which can easily be deallocated upon
failure, hence disabling the need for complex deallocation procedures
within C. This gives you control over defined contexts with ease. If
vital contexts repeatly fails, then you might want to think on plan b.

(Context-Oriented Programming =)

You're right, it isn't that hard to control if you are aware.
But maybe weekends are a bad time... :-)

Maybe I should take that as an insult :-)

Tobias
--
IMPORTANT: The contents of this email and attachments are confidential
and may be subject to legal privilege and/or protected by copyright.
Copying or communicating any part of it to others is prohibited and may
be unlawful.

[Frank Puck]

"Jacob" <ja***@yahoo.co m> wrote in message
news:MM******** ************@te lenor.com...

somehow. Following my company guidelines inter-library exception
throw/catch is not an option, so I need to use other mechanisms.

this is a stupid nonsensical restriction -- exceptions are intended for
reporting errors out of libraries