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.co m> wrote in message
news:2Z******** ************@te lenor.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::DisplayAnd ForceExit("Inte rnal 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::DisplayAnd ForceExit("Inte rnal 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.