Challenging GotW 66's moral

[George2]

Hello everyone,


In GotW #66, one of the moral is the exception handler of constructor should not do any like resource free task. I do not agree. Here is the quoated moral and my code to prove this moral will have memory leak.

Anything wrong with my analysis?

http://www.gotw.ca/gotw/066.htm

Moral #1: Constructor function-try-block handlers have only one purpose -- to translate an exception. (And maybe to do logging or some other side effects.) They are not useful for any other purpose.

class A
{
private:

int* p;

public:

    A()
    try
    {
        p = new int[10];

        // there are some other exceptions here
        
    }
    catch (bad_alloc)
    {
        // do not delete since bad_alloc means memory pointed by p is not allocated
    }
    catch (...)
    {
        // if we do not delete p, there will be memory leak
        // at this point, we are conflicting with Gotw 66's moral 1
        if (p) delete[] p;
    }
}

thanks in advance,
George

[weaknessforcats]

The example is not correct.

The correct code is:
[code=cpp]
class A
{
private:

int* p;

public:

A()
try
{
p = new int[10];

// there are some other exceptions here

}
catch (bad_alloc)
{
// do not delete since bad_alloc means memory pointed by p is not allocated
throw; //re-throw exception

}
catch (...)
{
// if we do not delete p, there will be memory leak
// delete p regardless.
delete[] p;
throw; //re-throw exception
}
}
[/code]

I have already covered this with you: Heap allocations in the current stack frame are not part of stack unwinding. Therefore, you have to delete the heap allocation. Then you have to either re-throw the original exception or throw a new one based on your exception design in your application.

Catching a bad_alloc might make sense if you are not using Windows - and I have covered that with you.

[George2]

Thanks weaknessforcats ,


I agree with all of your points, except the below one. I saw many programs, including MSDN samples, they catch bad_alloc. Why do you think it is bad idea (your previous reason is not strong, I think, even if Windows is using virtual memory, the case when there is bad_alloc still could happen)?

Catching a bad_alloc might make sense if you are not using Windows - and I have covered that with you.

regards,
George

[weaknessforcats]

Why do you think it is bad idea (your previous reason is not strong, I think, even if Windows is using virtual memory, the case when there is bad_alloc still could happen)?

One hour before bad_alloc, you see a message box: "Windows running low on resources". Thirty minutes before bad_alloc, you notice the hourglass appearing briefly here and there, Fifteen nmiutes before bad_alloc the hour glass is on most if the time. You machine response is sluggish. Five minutes before bad_alloc, operations that took the blink of an eys now take ten minutes. The hourslgass is constantly on. You notice the disc activity light is steady on. Your machine starts to vibracte across the floor, etc....

I have never seen a bad_alloc every thown from a VC++ compiled program.

You might try it. Just allocate large amounts in a loop and display the loop counter. See what happens.

[George2]

Thanks for sharing your experience, weaknessforcats !


Maybe some other situation will let us meet with the bad_alloc exception? For example, we allocate a vary large amount of memory than system virtual memory size?

One hour before bad_alloc, you see a message box: "Windows running low on resources". Thirty minutes before bad_alloc, you notice the hourglass appearing briefly here and there, Fifteen nmiutes before bad_alloc the hour glass is on most if the time. You machine response is sluggish. Five minutes before bad_alloc, operations that took the blink of an eys now take ten minutes. The hourslgass is constantly on. You notice the disc activity light is steady on. Your machine starts to vibracte across the floor, etc....

I have never seen a bad_alloc every thown from a VC++ compiled program.

You might try it. Just allocate large amounts in a loop and display the loop counter. See what happens.

regards,
George