Re: Nested exception handling
Thanks, Doug.
If I understand you correctly, I should be using return codes and not
exceptions
in the case of, say, failure to solve equations numerically because of lack
of convergence. I assume that exceptions would still be appropriate when
dynamic allocation fails because of insufficient memory. What about objects
where the constructor does several dynamic allocations, say, of arrays ?
Would a try/ catch block then be appropriate in the constructor ? Then if one
allocation fails, any already allocated memory can be released in the catch
block and the exception rethrown. This seems to be necessary because if a
constructor throws an (uncaught) exception, the destructor will never be
called.
"Doug Harrison [MVP]" wrote:
On Mon, 1 Oct 2007 20:30:01 -0700, Andrew
<Andrew@discussions.microsoft.com> wrote:
I am getting an internal compiler error C1001 when I use nested try blocks in
MS C++ 6.0. An example follows. The implementation of the method Change
causes the problem. Is this a compiler bug ? I can't find any syntax error.
#include <stdlib.h>
class ListInteger
{
public:
ListInteger(); // simple constructor
ListInteger(int length); // constructor
ListInteger(const ListInteger & rhs); // copy constructor (deep)
ListInteger operator=(const ListInteger & rhs); // assignment (deep
copy)
~ListInteger(); // destructor
int GetLength() const;
int GetInteger(int k) const;
void SetInteger(int k,int entry);
static void Change(ListInteger & X);
static int * intvec(int length);
static void del_intvec(int * q,int length);
private:
int * itsInteger; // array of integers indexed from zero
int itsLength; // length of list
};
// produces fatal error C1001: INTERNAL COMPILER ERROR
void ListInteger::Change(ListInteger & L)
{
try
{
ListInteger save = L;
try
{
//...
}
catch (...)
{
try
{
L = save;
//...
}
catch (...)
{
try
{
L = save;
//...
}
catch (...)
{
//...
throw;
}
}
}
save = L;
try
{
//...
}
catch (...)
{
try
{
L = save;
//...
}
catch (...)
{
try
{
//...
}
catch (...)
{
//...
throw;
}
}
}
}
catch (...)
{
//...
throw;
}
}
VC 2005 doesn't have any problem with it. That said, no matter what the
elided code looks like, it's very hard to imagine this can be a good use of
exceptions. It appears you're using exceptions as an alternative to return
codes on a 1:1 basis, but a major advantage of exceptions is that they
allow you to separate program logic from error handling. Well-written
programs contain few try/catch blocks; they instead rely on destructors of
local objects to perform whatever clean-up is necessary, and most functions
don't contain a try/catch block.
--
Doug Harrison
Visual C++ MVP