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

It should be safe.

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.)

You should also ensure that none of your destructors or swap functions throw an exception: http://www.ubookcase.com/book/Addiso...1lev1sec2.html

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.

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.

Thanks Bubba,


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

Quote:

---

Originally Posted by Bubba

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

Great sample, CornedBee!

Quote:

---

Originally Posted by CornedBee

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

Thanks cpjust,


Good online book. Money saving. :-)

Quote:

---

Originally Posted by cpjust

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