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,

Expand|Select|Wrap|Line Numbers

 
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

George2 wrote:

Quote:

Hello everyone,
>
>
Suppose I have some objects created on local function stack (not on
heap).

The C++ standard does define the words "heap" and "stack", but both mean
something different from what you are talking about.
Local variables go to automatic storage. Dynamic objects go to the free
storage.

Quote:

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.

Yes.

Quote:

>
Pseudo code like this,
>

Expand|Select|Wrap|Line Numbers

 
void func()

{

      Class1 inst1;

      Class2 inst2;

>

      ... // some operations

>

      return;

}

>
Does above code always safe? Are there any potential risks to leak
resources?

If Class1 and Class2 have proper destructors that release all acquired
resources, no. That is the RAII principle.

On Dec 21, 5:44*pm, George2 <george4acade...@yahoo.comwrote:

Quote:

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,
>

Expand|Select|Wrap|Line Numbers

 
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

If we encounter any exception within function destructor will not be
invoked, and there are high probability of leakage I bealieve.

Thanks,
Sachin

Sachin wrote:

Quote:

On Dec 21, 5:44Â*pm, George2 <george4acade...@yahoo.comwrote:

Quote:

>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,
>>
>

Expand|Select|Wrap|Line Numbers

 
>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

>
If we encounter any exception within function destructor will not be
invoked, and there are high probability of leakage I bealieve.

Your beliefs are wrong. If an exception is thrown, all local objects are
properly destroyed.

is such exception handling approach good?

re: is such exception handling approach good?

re: is such exception handling approach good?

re: is such exception handling approach good?

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about