Re: Handle C++ exception and structured exception together
* Pavel:
Alf P. Steinbach wrote:
* Pavel:
anon wrote:
George2 wrote:
Hello everyone,
I am learning set_se_translator, and there are some good resources
about how to translate structured exception into C++ exception, like,
http://www.codeproject.com/KB/cpp/seexception.aspx
LOL
this code looks like coming from a clown:
catch(CSeException *e)
{
e->ReportError(MB_OK | MB_ICONSTOP);
e->Delete();
}
Wondering what they do in Delete() method. Hope not "delete this"
I thought "delete this" was not bad-bad, although certainly not
ideal. Sometimes there is no good alternative to at least indirect
"delete this" or its equivalent ... or I simply do not know one. Do you?
The problem is mostly that with an exception there's no designated
"owner" that's responsible for deleting. And with a catch(...) you
have a memory leak. The code above is based on MFC exceptions, which
were a pre-standard hack to use exceptions in a language
implementation that didn't support exceptions.
Cheers, & hth.,
- Alf
I agree, in general catch(...) does not work for throwing pointers; but
in the example in question the structured exceptions are all inherited
from CSeException so they can be safely caught and deleted if needed.
Structured exceptions targeted C language, with no automatic stack
unwinding, kind of glorified setjmp()/longjmp() so throwing pointers and
deleting memory in the handler seems to be a more or less precise
mapping of the concept into the standard C++ syntax.
I believe the "clown" pan was aimed at "delete this" idea though.
* C++: I believe the "clown" comment was aimed at throwing pointers to
dynamically allocated objects. It's a recipe for disaster, because of
the lack of designated owner and possibility of "catch(...)". Using
"delete this", on the other hand, is a normal way to do destruction in
many situations, nothing wrong with that, although it is a power tool
that can be dangerous in untrained hands.
* Windows: structured exception handling (SEH) is an operation system
API way to communicate failure that targets no specific language, but
does require language support. Most of it is undocumented. As I recall
Matt Pietrik (not sure of speling) wrote a series of articles going into
depth of the undocumented aspects, including typical language support.
* MFC exceptions (MFC is an old C++ GUI framework from Microsoft):
throwing pointers had, as far as I know, nothing to do with SEH, and
these exceptions were not targeted at C, since MFC was and is a C++
class framework. Rather, it probably had to do with this exception
handling being implemented via macros and nifty hacking, before C++
exception handling became available. Keep in mind that MFC predates the
C++ standard, and that C++ exception handling wasn't frozen until late
in the standardization process.
The pre-standard macro way (example lifted from [1]):
TRY
{
// Do something to throw an exception.
AfxThrowUserException();
}
CATCH(CException, e)
{
if (m_bPassExceptionsUp)
THROW_LAST();
if (m_bReturnFromThisFunction)
return;
// Not necessary to delete the exception e.
}
END_CATCH
Using standard C++ exception handling the cleanup that was hidden in the
macros must be done manually:
try
{
// Do something to throw an exception.
AfxThrowUserException();
}
catch(CException* e)
{
if (m_bPassExceptionsUp)
throw;
if (m_bThrowDifferentException)
{
e->Delete();
throw new CMyOtherException;
}
if (m_bReturnFromThisFunction)
{
e->Delete();
return;
}
e->Delete();
}
Of course, this mess is on its own a good reason not to use MFC... ;-)
Cheers, & hth.,
- Alf
Notes:
[1] <url: http://msdn2.microsoft.com/en-us/library/19z28s5c.aspx>
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?