Exception checking memory allocation. How?

Discussion in 'C++' started by benben, Jul 30, 2005.

  1. benben

    benben Guest

    > 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, Jul 30, 2005
    #1
    1. Advertising

  2. benben

    benben Guest

    > 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
    benben, Jul 30, 2005
    #2
    1. Advertising

  3. 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
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jul 30, 2005
    #3
  4. benben

    Jacob Guest

    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!
    Jacob, Jul 30, 2005
    #4
  5. benben

    benben Guest

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


    All software crashes at some point...
    benben, Jul 30, 2005
    #5
  6. 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
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jul 30, 2005
    #6
  7. "Jacob" <> wrote in message
    news:...
    > 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
    Ivan Vecerina, Jul 30, 2005
    #7
  8. benben

    Jacob Guest

    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.
    Jacob, Jul 30, 2005
    #8
  9. 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.
    Tobias Blomkvist, Jul 30, 2005
    #9
  10. 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
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jul 30, 2005
    #10
  11. 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
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jul 30, 2005
    #11
  12. benben

    Jacob Guest

    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.
    Jacob, Jul 30, 2005
    #12
  13. 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.
    Tobias Blomkvist, Jul 30, 2005
    #13
  14. benben

    Jacob Guest

    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.
    Jacob, Jul 30, 2005
    #14
  15. benben

    Jacob Guest

    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... :)
    Jacob, Jul 30, 2005
    #15
  16. 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.
    Tobias Blomkvist, Jul 30, 2005
    #16
  17. benben

    Frank Puck Guest

    "Jacob" <> wrote in message
    news:...
    > 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
    Frank Puck, Jul 31, 2005
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kwijibo28
    Replies:
    6
    Views:
    1,129
    tom_usenet
    Aug 11, 2003
  2. Ken
    Replies:
    24
    Views:
    3,859
    Ben Bacarisse
    Nov 30, 2006
  3. Kev
    Replies:
    3
    Views:
    337
  4. chris
    Replies:
    6
    Views:
    987
    chris
    Oct 28, 2005
  5. Bjarke Hammersholt Roune
    Replies:
    14
    Views:
    1,182
    Bjarke Hammersholt Roune
    Mar 6, 2011
Loading...

Share This Page