is such exception handling approach good?

[George2]

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,

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

[weaknessforcats]

This code is never safe.

When an exception is thrown, the current stack frame is not cleaned up. That is, the destructors for the local objects are not called.

That is, an exception is a hard go-to-the-catch-block.

This means you can't just willy-nilly use exceptions. You need to design for them. In your example, the two stack objects should be allocated on the heap. Then inside the function you catch the exception, delete the objects, and then rethrow it now that the local stack frame is cleaned up:

void func()
{
    Class1* inst1 = 0;
    Class2* inst2 = 0;
    try
    {
     inst1 = new Class1;
     inst2 = new Class2;
 
      // some operations
      throw 25;
    }
    catch (...)
    {
        delete inst1;
        delete inst2;
        throw;       //rethrow the excpetion
    }
      return;
}
 

[George2]

Thanks weaknessforcats,


1.

I think we are talking about different things. :-)

This is your code,

    Class1* inst1 = 0;
    Class2* inst2 = 0;
     inst1 = new Class1;
     inst2 = new Class2;
 

This is my code

    Class1 inst1;
    Class2 inst2;
 

My object instances are on the stack, but your object instances are on the heap (only pointer on stack). I think in my situation, it is safe and does not leak any resources if there are any exception thrown when stack unwinding makes us go out of the stack, the destructor is automatically called (since when we are out of the current stack during stack unwinding, the lifecycle of inst1 and inst2 expired and their destructors are called).

2. what do you mean the stack is not cleaned up?

I think in my situation the destructors are called since during stack unwinding, the lifecycle of objects' instances are expired and their destructors should be called.

This code is never safe.

When an exception is thrown, the current stack frame is not cleaned up. That is, the destructors for the local objects are not called.

Please feel free to correct me if I am wrong.


regards,
George

[weaknessforcats]

I think in my situation the destructors are called since during stack unwinding, the lifecycle of objects' instances are expired and their destructors should be called.

Yes, I was incorrect. I meant to say that heap allocations are not unwound in the current stack frame. Stack objects will have destructors call provided the exception is caught. Otherwise, they're not. Heap allocations will remain unless you delete them.

I so seldom use stack objects because of the risks associated with them when used as function arguments. It's too easy for a reference or an address of one of these stack objects to become a member of another object that is returned. Later, that reference or address may be no good and crash the program.

[George2]

Thanks weaknessforcats,


I understand your points now. I think using auto_ptr can solve this issue when you forget to call delete explicitly, right?

Do you agree using auto_ptr and put cleanup code in destructor can solve all the issues?

Yes, I was incorrect. I meant to say that heap allocations are not unwound in the current stack frame. Stack objects will have destructors call provided the exception is caught. Otherwise, they're not. Heap allocations will remain unless you delete them.

I so seldom use stack objects because of the risks associated with them when used as function arguments. It's too easy for a reference or an address of one of these stack objects to become a member of another object that is returned. Later, that reference or address may be no good and crash the program.

regards,
George

[weaknessforcats]

I think using auto_ptr can solve this issue when you forget to call delete explicitly, right?

Do you agree using auto_ptr and put cleanup code in destructor can solve all the issues?

Avoid using auto_ptr. It doesn't work like you think. See Effective STL by Scott Meyers Item #8.

However, the approach is correct. Use a smart pointer with built-in reference counting. There is an article I wrote in the Howtos for C++ on Handle classes. In that article is a template for a reference-counted handle that you are free to use in your applications. It works very like the shared_ptr that's coming out with the new C++.

[George2]

Thanks weaknessforcats,

1.

Avoid using auto_ptr. It doesn't work like you think. See Effective STL by Scott Meyers Item #8.

Why in my sample, I can not use auto_ptr to solve this issue to make sub-components' destructor called automatically? More descriptions please?

2. I am interested in your article, could you post a link please?

However, the approach is correct. Use a smart pointer with built-in reference counting. There is an article I wrote in the Howtos for C++ on Handle classes. In that article is a template for a reference-counted handle that you are free to use in your applications. It works very like the shared_ptr that's coming out with the new C++.

regards,
George