Re: Exception handling?
On Jun 21, 6:13 pm, "RB" <NoMail@NoSpam> wrote:
In my below foobar first attempt to try exception handling I don't unders=
tand
the following aspects: (my code at bottom after these framework pastes=
)
1. I must not be doing something correct because even though both
my CATCH and AND_CATCH call stuff on return that appears to be
deleting the exception and taking care of various cleanup.
I would also recommend that you forget TRY, CATCH and the rest of MFC
macros. They are a sad leftover from the time MS C++ compiler didn't
implement exceptions (but MFC people wanted to have them).
MFC has that nasty design flaw with exception handling that it uses
exception __pointers__ (I guess also due to said lack of exceptions in
compiler in early days). This is not normal in C++ code, and a
horrific error. Consequence of these pointers is that design of
ownership of said pointers is complicated (well, not much, but still):
when you catch an MFC exception, and you don't want to re-throw it,
you must call Delete() on it (__NOT__ e.g. delete pException;)
I use C++ try/catch and a macro DEL_ON_EXIT, that I put on top of
every catch where I want to handle the exception, e.g. like so:
try
{
workworkwork();
}
catch(CException* p)
{
DEL_ON_EXIT(p);
p->ReportError();
}
DEL_ON_EXIT calls p->Delete() on block exit.
Warning: I'll tear apart code below, it's not good at all. ;-)
void CFileHandlingDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
ar << FileID; // DWORD
ar << VerData.Ver << VerData.CpyRt << VerData.Corp;
ar.SerializeClass(RUNTIME_CLASS(CMapStringToString));
ExpMap1.Serialize(ar);
} =
else
{
CString E;
TCHAR szErrMsg[255];
TRY
{
ar >> FileID;
if (FileID != 0x1234ABCD)
{ // FileID mismatch =
AfxThrowUserException( );
This is bad. CUserException is a special exception type. You use it
like so: first, you inform the user what went wrong, then you throw it
and leave it to MFC to "handle". MFC actually ignores it, assuming
that user was already informed about what went wrong.
So in this case, you first inform the user what went wrongm then
throw. What happens in this particular case is that it goes to
document's ReportSaveLoadException and gets ignored there.
So... Given how CUserException is specified, inform the user about
what went before throwing. That's rule 0 of CUserException. Rule 1 is:
avoid using it. Given that you need to inform the user what's
happening, it's better to throw an exception that contains whatever
info about the error you want (including message to the user) catch it
and report it higher up the stack (most likely, that means letting it
be handled by MFC somewhere). There's a catch WRT
ReportSaveLoadException and that idea, though, so for now, just inform
the user and throw "user" exception.
}
ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp;
ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); // =
WriteClass CmStS's data
ExpMap1.Serialize(ar); // CMapStringToString's key=
s and values
}
This is bad, and it shows massive confusion WRT exceptions. In 99% of
cases, if you throw and catch same exception type in one function,
you're doing it wrong.
In fact, a piece of advice for a beginner: in 99% of cases, if you
think that you need to write a try/catch, you're doing it wrong. What
you should do instead is ask yourself "if I throw here, where is
exception caught?" Find the answer to that, and you'll find that you
don't need a try/catch. (Exception to that rule: various "creation"
functions of MFC that you can override, e.g. PreCreateWindow,
OnCreate, OnInitDialog, stuff like that especially e.g. OnCreate
should not allow that exception escapes from them.
CATCH( CUserException, e )
{
E = _T("BAD FileID, RB from inside CATCH\n");
AfxMessageBox( E );
return;
}
AND_CATCH( CException, e )
{
// For other exception types, notify user here.
e->GetErrorMessage(szErrMsg, 255);
E = _T("RB from inside AND_CATCH\n");
E += szErrMsg;
AfxMessageBox( E );
return;
}
END_CATCH
// No exception thrown.
}
}
In your case, there should not be ANY try/catch statements in the
whole of Serialize. What you should do, instead, is let exceptions go
through. They will end up in ReportSaveLoadException and be handled
there by MFC.
Goran.
P.S. Don't forget: you are not allowed to write try/catch
statements ;-). If you do, you have 99% chance that you're doing it
wrong. Good C++ code of today has RIDICULOUSLY small number of try/
catch-es in ti.