try...catch vs TRY...CATCH

try...catch vs TRY...CATCH

Post by S2V2aW4gVG » Wed, 12 Jul 2006 18:21:02


Dear All,

I want to know the different between try...catch and the MFC version
TRY...CATCH.
Is there any document on the internet?

I am writing MFC application, which version of exception handle is better?

Thanks.
Kevin Tang
 
 
 

try...catch vs TRY...CATCH

Post by Alex Blekh » Wed, 12 Jul 2006 20:31:36


Just press F12 to go to definition while caret is on "TRY"
token. Basically, TRY/CATCH use language's try/catch (with
addition of small MFC bookeeping, see yourself definitions
of TRY/CATCH in afx.h file). Long time ago when not every
compiler supported exceptions and those that supported could
differ considerably MS defined TRY/CATCH macros to implement
MFC exceptions regardless of used compiler. Nowadays, MFC's
TRY/CATCH use C++ language's try/catch.


TRY/CATCH with MFC exceptions classes (or derived from
CException).

For more info see:

"Exception Processing"
http://www.yqcomputer.com/

HTH
Alex

 
 
 

try...catch vs TRY...CATCH

Post by Ulrich Eck » Wed, 12 Jul 2006 20:34:39


'try' and 'catch' are C++ features, 'TRY' and 'CATCH' are part of the MFC,
as you noted. The MFC ones probably date back to before the C++ ones were
widely implemented and available and have been maintained for backward
compatibility.


I found the info in the MSDN, http://www.yqcomputer.com/


The C++ one is portable, with documented (though not completely implemented,
in case of MS compilers) semantics and behaviour, which is why I'd prefer
that. Now, when using e.g. CFile, there are some operations that throw MFC
style exceptions, nothing you can about that. Therefore, you have to catch
these using the MFC style, too. Just keep in mind that you can not throw
one style and catch the other. Other than that, you can freely mix styles.

Uli
 
 
 

try...catch vs TRY...CATCH

Post by David Wilk » Wed, 12 Jul 2006 21:58:15


Alex:

Are you saying you cannot (or should not) catch CException* with
try/catch? Surely you can, no?

David Wilkinson
 
 
 

try...catch vs TRY...CATCH

Post by Alex Blekh » Wed, 12 Jul 2006 22:40:26


Of course you can. Also, MS itself encourages to use C++
try/catch instead of MFC TRY/CATCH. However, the problem is
that you cannot stick with C++ handling and forget about
MFC's one. It always leaks, like in CFile usage, as Ulrich
pointed already. There are other places where MFC throws its
exceptions. Then in all these places you need to remember
that MFC exceptions are different (require deleting) from
the others. After while your code becomes inconsistent and
it's even worse than sticking with one of the handling
methods. So, I find it easier to stick with MFC exceptions
while making my own exceptions uniform with MFC's ones (by
deriving them from CExceptions or others). Then I don't need
to remember anything and can write same exception handling
code everywhere.
 
 
 

try...catch vs TRY...CATCH

Post by David Wilk » Wed, 12 Jul 2006 22:52:53


Hi Alex:

What does deleting the CException pointer have to do with whether you
use try/catch or TRY/CATCH?

David Wilkinson
 
 
 

try...catch vs TRY...CATCH

Post by Ulrich Eck » Wed, 12 Jul 2006 23:23:01


In idiomatic C++, you throw exceptions by value, which is why they must be
copy-constructible. Therefore, again in idiomatic C++, you never throw
pointers no new'ed exceptions that you then have to delete.
Other than that, the TRY/CATCH/etc macros from MFC are (in newer versions of
the environment) implemented in terms of the C++ try/catch mechanisms. So,
everything you can do with TRY/CATCH/etc can be done with try/catch. This
doesn't mean you should, as it only causes confusion to the next person
reading it.

Uli
 
 
 

try...catch vs TRY...CATCH

Post by Alex Blekh » Thu, 13 Jul 2006 01:09:00


If I use try/catch, then usually exceptions are thrown by
value and handled by reference. I.e., I don't need to
perform any special clean up for exception object. MFC
throws pointer to object, allocated with `new' and obligates
me to call e->Delete() in exception handler code. Now I have
two options:

1. To use try/catch, therefore
+ code looks more conforming C++ standard
+ my exceptions can be thrown as I wish
- MFC exceptions must be caught by pointer to CException
(or derivative)
- MFC exception must be deleted in catch block
- my exceptions require separate catch clause, or..
- my exceptions are derived from CException and play by
MFC rules

2. To use TRY/CATCH, therefore
- code looks less conforming C++ standard
- my exceptions derived from CException and play by MFC
rules
+ not necessary to delete both MFC and my exceptions
+ not necessary to separate catch clauses for MFC and my
exceptions
+ my exception will require GetErrorMessage or similar
method anyway, so why not to derive it from CException (or
other MFC exception) all the time.

Considering all this I find using TRY/CATCH approach being
more consistent and less error prone.
 
 
 

try...catch vs TRY...CATCH

Post by Doug Harri » Thu, 13 Jul 2006 01:15:27

On Tue, 11 Jul 2006 16:23:01 +0200, Ulrich Eckhardt



I don't think this causes any confusion at all:

catch (CException* p)
{
...
p->Delete(); // or throw;
}

In fact, it will save you some time if you ever find yourself in a
heterogeneous exception environment, because you won't have to rewrite all
the macros. FWIW, ISTR reading documentation that states that the keywords
should be considered preferred to the macros.

The only real problem with using try/catch and MFC exceptions is with
catch(...). If it's possible for catch(...) to catch an MFC exception, it
must rethrow, or you run the risk of a memory leak, since you can't call
Delete(). But note that the exceptions thrown by functions like
AfxThrowMemoryException() have static storage duration, so Delete() amounts
to a no-op for them. This is why you must call Delete() instead of using
the delete operator.

Finally, the heterogeneous exception environment mentioned above introduces
some new problems into MFC programs, which I talk about here:

http://www.yqcomputer.com/ #Q6

--
Doug Harrison
Visual C++ MVP