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!

[benben]

> 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).
I don't know about commonality but allocating the exception object thrown on
the heap really doesn't seem to have any advantages. You won't have a C++
exception for stack overflow. And besides, you have to delete the thrown
exception if it is newed in a context where a garbage collector is absent.

Most of the time it is the type the object thrown that is important. Only
occasionally I have to check the internal information carried by the
exception thrown.

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?

It really depends on how the object is to be used. Here are some facts:
*The stack is popped off when the execution goes out of scope, so you can
preserve anything on the stack beyond the scope. However, you don't have to
worry about manually deleting the object.
*Stack allocation is much more efficient than other means in most systems.
*The stack is limited, often much smaller than max heap you can acquire
mostly. For small objects, this isn't an issue. But for large objects it
should be taken care of. A common practice is to utilize RAII (for example,
std::string)

Ben

[benben]

> It really depends on how the object is to be used. Here are some facts:

*The stack is popped off when the execution goes out of scope, so you can
preserve anything on the stack beyond the scope. However, you don't have to worry about manually deleting the object.

I meant you CANNOT preserve anything on the stack beyond the scope of
course. Excuse my typo.

Ben

[Julián Albo]

Jacob wrote:

It is common practice (I've heard) to always catch
allocation exceptions from "new".
Not always. In a small program used in a environment when enough memory is
always available, and wit users with some commnon sense, you can just let
the program abort.
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).
The common procedure is to do something according to the guidelines written
by the designers of the project.
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?

Allocate objetcs with new when required, and forget the word "absolutely".
Study the limitations of your platform and his non-standard ways of
checking it.

--
Salu2

[Jacob]

Julián Albo wrote:

The common procedure is to do something according to the guidelines written
by the designers of the project.
Well, that is me in this case, so therefore I go to
the gurus for advice :-)
Allocate objetcs with new when required, and forget the word "absolutely".
Study the limitations of your platform and his non-standard ways of
checking it.

My platform is not necesserily my customers platform.
Hardware varies. And crashing is _not_ an option.

[benben]

> My platform is not necesserily my customers platform.

Hardware varies. And crashing is _not_ an option.

All software crashes at some point...

[Julián Albo]

Jacob wrote:

Allocate objetcs with new when required, and forget the word
"absolutely". Study the limitations of your platform and his non-standard
ways of checking it.

My platform is not necesserily my customers platform.
Hardware varies. And crashing is _not_ an option.

Study the limitations of your customer's platforms and his non-standard
ways of checking it ;)

--
Salu2

[Ivan Vecerina]

"Jacob" <ja***@yahoo.com> wrote in message
news:2Z********************@telenor.com...

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).
In practice, you first of all make sure that your code
is exception-safe. That is, if an exception is thrown,
the current operation is stopped or cancelled gracefully.
In particular, you should use RAII to avoid memory
or resource leaks.

Then you should only need to care about error handling at
the top-level of a program (e.g. the agent that generates
commands, or top-level functions that handle user-
generated commands). Only there do you care and know how
to report the failure of an operation.
Sometimes, at an intermediate level, it is possible
to release resources or reset/alter some environment
parameters to attempt the same operation again.
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?

What is 'absolutely' required?
Objects should be allocated dynamically when it is
suitable to manually control their lifetime, and stack-
based or global objects are not an adequate solution.
This is a matter of design.
Also, dynamic allocation does not imply using 'new'
(think in terms of containers when possible...).

When a stack can overflow and how this error condition
is handled is unfortunately a platform-specific detail.
There is no fully portable solution in standard C++.

Sometimes large objects or data stacks are indeed
allocated on the heap just because this provides better
control over object allocations and error handling
(e.g. a recursive algorithm can be rewritten to use
an std::vector rather than the program stack, to better
detect and handle excessive recursion).
I hope this helps,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

[Tobias Blomkvist]

Jacob sade:

What would be a common procedure (path of
sequence) after such an event has occured?

GUI::DisplayAndForceExit("Internal run-time error. Auto-shutdown
commencing. All unsaved data will be lost. Be well!");

:)

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:

What would be a common procedure (path of
sequence) after such an event has occured?

GUI::DisplayAndForceExit("Internal run-time error. Auto-shutdown
commencing. All unsaved data will be lost. Be well!");

Why do you suggest a shutdown?

You just encouter a memory allocation failure, but the program
should be able to continue. Locally, the allocating class should
handle the problem (technically how, I haven't got an answer for yet),
and at the application level the event should be flagged to the GUI
somehow. Following my company guidelines inter-library exception
throw/catch is not an option, so I need to use other mechanisms.

[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.com> wrote in message
news:MM********************@telenor.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