Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Exception checking memory allocation. How?

Reply
Thread Tools

Exception checking memory allocation. How?

 
 
benben
Guest
Posts: n/a
 
      07-30-2005
> 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


 
Reply With Quote
 
 
 
 
benben
Guest
Posts: n/a
 
      07-30-2005
> 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


 
Reply With Quote
 
 
 
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      07-30-2005
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
 
Reply With Quote
 
Jacob
Guest
Posts: n/a
 
      07-30-2005
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!
 
Reply With Quote
 
benben
Guest
Posts: n/a
 
      07-30-2005
> My platform is not necesserily my customers platform.
> Hardware varies. And crashing is _not_ an option.


All software crashes at some point...



 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      07-30-2005
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
 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      07-30-2005
"Jacob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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




 
Reply With Quote
 
Jacob
Guest
Posts: n/a
 
      07-30-2005
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.
 
Reply With Quote
 
Tobias Blomkvist
Guest
Posts: n/a
 
      07-30-2005
Jacob sade:
> What would be a common procedure (path of
> sequence) after such an event has occured?


GUI:isplayAndForceExit("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.
 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      07-30-2005
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Checking list by using of exception Nader Python 3 06-14-2008 09:29 AM
Exception of type 'System.Web.HttpUnhandledException' wasthrown.Exception has been thrown by the target of an invocation.System.WebSystem.Exception jobs ASP .Net 1 11-16-2007 05:57 PM
while executing my client program i get the exception javax.naming.LinkException: [Root exception is javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining if plz anybody know how to solve this problem then mahesh Java 0 03-08-2007 12:26 PM
Checking System Memory In Windows 98 =?Utf-8?B?VGVxbHVtcA==?= Microsoft Certification 2 12-04-2005 04:17 PM
Differences between Sony Memory Stick & memory Stick Pro vs Memory Stick Duo? zxcvar Digital Photography 3 11-28-2004 10:48 PM



Advertisments