Re: Handle C++ exception and structured exception together
* Pavel:
...
Wondering what they do in Delete() method. Hope not "delete this"
...
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.
I disagree. "delete this" fragment was brought up by the commenter (see
above), it was not in the original post.
It's a recipe for disaster, because of
the lack of designated owner and possibility of "catch(...)". U
In general, it is a recipe for a memory leak (whether a memory leak is
always and patently a disaster is a different matter).
It can easily lead to memory leaks, yes, and it can also easily lead to
double destruction. Both are generally disasters. Although possibly
not immediate disasters in the sense of an immediate program crash.
In particular,
when only structured exceptions (thrown by the underlying C API we do
not control) are processed by throwing a pointer to an exception and all
such exceptions have a common base class (in the example, CSeException),
it seems acceptable to me (and will not create a memory leak).
First, since the code is using MFC exceptions it's not only SEH
exceptions that are handled that way.
Second, the conclusion "and will not create a memory leak" does not follow.
On the contrary, since SEH exceptions can be asynchronous and can occur
at any point (e.g. for dereferencing a nullpointer), translating them to
C++ throwing of pointer to dynamically allocated exception object is
very likely to result in a memory leak, unless all the code is under
your control -- and even then...
I am just
trying to keep in mind the original problem: processing Windows
sructured exceptions in C++ code.
Not a big deal, except it's necessarily C++ implementation-specific, in
particular possibly requiring special compiler switches.
"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.
Completely agree.
* 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.
Well, it is documented in the enough details to catch them in C.
No, the SEH documentation is for Microsoft's C and C++ language extensions.
"No
specific language" is correct for the exception client but not for the
code that raises exception (it is C API, after all).
No, it's not a C API.
The documented language extensions are for C and C++. However, it's not
documented how they work together with the (operating system) API, i.e.
how these extensions are implemented or what you'd do without them. At
least, it didn't use to be documented, and I haven't checked lately.
However, that's largely off-topic in clc++.
Language support (beyond setjmp()/longjmp() support which would
introduce platform dependency anyway, by C standard) was not really
required to solve the problem, it was just usual old Microsoft's way of
presenting their facilities in the most nonstandard way possible.
* 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.
Well that's where I would partly disagree. What you are saying is a
possibility but why exactly Microsoft introduced this "MFC standard way"
of throwing will probably stay unknown forever. Theoretically it is
possible it did not have anything to do with SEH but it is obvious to me
that unconditionally leaving the destruction of the exception
information up to the exception handler is so consistent with the
structured exceptions and old C ways (again, I heard your "no specific
language" but ? was the primary API target and implementation language
(with some assembler) so I would not bet much on that.
But it is all misses the point (almost). The reason why I mentioned the
MFC exception is because the code in the question took MFC base
exception to handle Windows structured exceptions (even though the did
not have to do it):
class CSeException : public CException
{
...
and then the followed the regular MFC practice of throwing the pointers.
The resulting code and suggested framework seem reasonably save to me as
long as the users will use MFC conventions consistently (which they will
have trouble not to do anyway as the solution introduces dependencies on
MFC).
Following MFC (cleanup) conventions consistently is difficult because
they are conventions that must be implemented manually, as opposed to
the automatic cleanup functionality of standard C++ exceptions.
...
Of course, this mess is on its own a good reason not to use MFC... ;-)
Agree, I never liked MFC myself. Even now I use C API on Windows --
"When in Rome .." -- and AFAIK "Romans" do not use MFC for their killer
apps -- or maybe they do now but before they did not.
AFAIK the Romans use WTL.
Cheers, & hth.,
- Alf
--
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?