Re: is such exception handling approach good?

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