is such exception handling approach good?

This is a discussion on is such exception handling approach good? within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, Suppose I have some objects created on local function stack (not on heap). And I allocate and free ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    is such exception handling approach good?

    Hello everyone,


    Suppose I have some objects created on local function stack (not on heap). And I allocate and free all the related resources in the constructor and destructor (e.g. memory and file handles). And I do not implement explicit exception handling code in the function for resource free purpose, and simply rely on destructor to free resources if exception occurs, that is,

    1. when exception occurs and the exception triggers us to go out of current function stack to the caller to find exception handlers;
    2. since objects are allocated on local stack, when exception triggers us to go out of current stack to its caller to find exception handler, the lifecycle of local objects on local stack will expire, and its related destructor will be invoked and free resources.

    Pseudo code like this,

    Code:
    void func()
    {
          Class1 inst1;
          Class2 inst2;
    
          ... // some operations
    
          return;
    }
    Does above code always safe? Are there any potential risks to leak resources?


    thanks in advance,
    George

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    It should be safe.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Provided the objects themselves are implemented correctly.

    Of course, there are other things that are part of exception safety. Most importantly, you can never allow your function to be aborted by an exception while any objects are in an inconsistent state. E.g. this copy assignment operator of a string-like class is unsafe:
    Code:
    mystring & mystring::operator =(const mystring &rhs)
    {
      delete[] m_data;
      m_data = new char[rhs.size() + 1];
      std::memcpy(m_data, rhs.m_data, rhs.size() + 1);
      return *this;
    }
    The reason: if the allocation fails, m_data is pointing at invalid memory. The object is in an invalid state.

    (The operator is also unsafe regarding self-assignment, but that's a different issue.)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    You should also ensure that none of your destructors or swap functions throw an exception: http://www.ubookcase.com/book/Addiso...1lev1sec2.html

  5. #5
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,261
    You've just described the basics of RAII. Asside from the few additional notes others are posting, that's basically the way to do it.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #6
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    The only time where it is difficult to use RAII is inside Win32 code or MFC code. The object lifetimes of Windows objects and C++ objects are not identical.

    Say if you try to instantiate a DC object inside of your constructor for your window your code will bail. This is because the window DC is not valid in the constructor because the window is not valid. So just because it's a valid C++ object does not mean it's a valid Windows object. Likewise if you try to clean up in your destructor, the DC is already invalid because usually WM_CLOSE has already been issued to your window long before the destructor was called.

    Other than that I normally try to stick with RAII as much as possible.
    Last edited by VirtualAce; 12-21-2007 at 03:56 PM.

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Bubba,


    I do not quite understand the context. Do you have some pseudo code?

    Quote Originally Posted by Bubba View Post
    The only time where it is difficult to use RAII is inside Win32 code or MFC code. The object lifetimes of Windows objects and C++ objects are not identical.

    Say if you try to instantiate a DC object inside of your constructor for your window your code will bail. This is because the window DC is not valid in the constructor because the window is not valid. So just because it's a valid C++ object does not mean it's a valid Windows object. Likewise if you try to clean up in your destructor, the DC is already invalid because usually WM_CLOSE has already been issued to your window long before the destructor was called.

    Other than that I normally try to stick with RAII as much as possible.

    regards,
    George

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Great sample, CornedBee!


    Quote Originally Posted by CornedBee View Post
    Provided the objects themselves are implemented correctly.

    Of course, there are other things that are part of exception safety. Most importantly, you can never allow your function to be aborted by an exception while any objects are in an inconsistent state. E.g. this copy assignment operator of a string-like class is unsafe:
    Code:
    mystring & mystring::operator =(const mystring &rhs)
    {
      delete[] m_data;
      m_data = new char[rhs.size() + 1];
      std::memcpy(m_data, rhs.m_data, rhs.size() + 1);
      return *this;
    }
    The reason: if the allocation fails, m_data is pointing at invalid memory. The object is in an invalid state.

    (The operator is also unsafe regarding self-assignment, but that's a different issue.)

    regards,
    George

  9. #9
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks cpjust,


    Good online book. Money saving. :-)

    Quote Originally Posted by cpjust View Post
    You should also ensure that none of your destructors or swap functions throw an exception: http://www.ubookcase.com/book/Addiso...1lev1sec2.html

    regards,
    George

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. In a game Engine...
    By Shamino in forum Game Programming
    Replies: 28
    Last Post: 02-19-2006, 10:30 AM
  2. Exception handling
    By Mortissus in forum C++ Programming
    Replies: 3
    Last Post: 02-15-2005, 07:35 PM
  3. Exception handling
    By hariharanpalani in forum C++ Programming
    Replies: 2
    Last Post: 02-04-2005, 04:33 AM
  4. ATL exception handling
    By rzcodeman in forum Windows Programming
    Replies: 1
    Last Post: 06-10-2004, 06:19 PM
  5. Rate My Application: File Exception Handling
    By KingZoolerius66 in forum C++ Programming
    Replies: 5
    Last Post: 12-14-2003, 09:29 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21