Re: is such exception handling approach good?

Your object's conctructor is not exception safe. If any of member
initializations drops an exception, all already initialized pointers will be
just left as is.

"Alex Blekhman" <tkfx.REMOVE@xxxxxxxxx> wrote in message
news:u6as0ZIRIHA.2376@xxxxxxxxxxxxxxxxxxxxxxx

Suppose you have the class:

class AllInOne
{
...

private:
BYTE* m_pBuf;
DBConn* m_pConn;
FILE* m_fLog;
};

Now you have two options:

1. Establish defined state of the object in constructor:

AllInOne::AllInOne() :
m_pBuff(new BYTE[42]),
m_pConn(OpenDB(...))
m_fLog(fopen(...))
{
// do other stuff
}

Then you can reliably use its methods:

BYTE AllInOne::GetData(int i)
{
return m_pBuff[i];
}

void AllInOne::RetrieveData()
{
m_pConn->FillBuff(m_pBuff, 42);
}

etc.

2. Create "simple" object first, then create necessary part separately:

AllInOne::AllInOne() :
m_pBuff(NULL),
m_pConn(NULL)
m_fLog(NULL)
{
}

AllInOne::InitBuff()
{
if(!m_pBuff)
m_pBuff = new BYTE[42];
else
assert("Cannot init the buffer twice!");
}

AllInOne::InitDBConn()
{
if(!m_pConn)
m_pConn = OpenDB(...);
else
assert("Cannot init DB twice!");
}

etc.

Now all of class' methods must paranoicaly check internal state and hope
for the best that user won't forget to call relevant initializer
functions:

BYTE AllInOne::GetData(int i)
{
if(m_pBuff)
return m_pBuff[i];
else
// deal with error
}

void AllInOne::RetrieveData()
{
if(m_pConn)
{
if(m_pBuff)
m_pConn->FillBuff(m_pBuff, 42);
else
// deal with error
}
else
{
// deal with error
}
}


In my other reply I posted a link to the excerpt from Strostrup's TC++PL.
He discusses the topic in details there.

Alex



.

Loading