C++/MFC and exceptions- catch(...)=bad? 
Author Message
 C++/MFC and exceptions- catch(...)=bad?

Is it generally considered bad to use catch(...) exception handlers?
It seems doing so can easily lead to memory leaks unless ALL other
exceptions are handled properly.

For example:

try
{
    throw new CException();

Quote:
}

catch(...)
{

Quote:
}

This will result in a memory leak. While this example is clear it gets more
interesting when you call functions that may throw numerous exception types.
If I understand this correctly, you must have a catch handler for all
exception types and free all the memory, as you can not use a catch(...)
handler since you will lose the exception generated (and if it was allocated
on the heap there is a memory leak then.)

It would seem then that catch(...) should always rethrow the exception OR
terminate the program otherwise a memory leak may result, unless you are
absolutely sure that all other exceptions will be handled, so this would
REQUIRE catch handlers for all other exception type cases.  For the most
part in MFC this would probably just mean handling catch(CException *) but
some are not even CExceptions, and then if you have user defined exceptions
you would have to catch those as well specifically or suffer a memory leak.

Am I misunderstanding this, or is there some other method of handling this
properly.



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
You can try to do

try
{
    Do stuff

Quote:
}

catch (CException* pEx)
{
    Handle exception
    pEx->Delete();

Quote:
}

Any exceptions that are thrown by MFC are derived from the CException, so
code above will catch them. I guess it might not handle some low-level
exceptions, like zero divide, overflow, etc., but you should try.

Quote:

>Is it generally considered bad to use catch(...) exception handlers?
>It seems doing so can easily lead to memory leaks unless ALL other
>exceptions are handled properly.

>For example:

>try
>{
>    throw new CException();

>}
>catch(...)
>{

>}

>This will result in a memory leak. While this example is clear it gets more
>interesting when you call functions that may throw numerous exception
types.
>If I understand this correctly, you must have a catch handler for all
>exception types and free all the memory, as you can not use a catch(...)
>handler since you will lose the exception generated (and if it was
allocated
>on the heap there is a memory leak then.)

>It would seem then that catch(...) should always rethrow the exception OR
>terminate the program otherwise a memory leak may result, unless you are
>absolutely sure that all other exceptions will be handled, so this would
>REQUIRE catch handlers for all other exception type cases.  For the most
>part in MFC this would probably just mean handling catch(CException *) but
>some are not even CExceptions, and then if you have user defined exceptions
>you would have to catch those as well specifically or suffer a memory leak.

>Am I misunderstanding this, or is there some other method of handling this
>properly.



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
So that means when using MFC you should ALWAYS try to catch(CException *),
using just a catch(...) handler is unacceptable  since it will possibly
result in a memory leak.   I think that the catch(...) handler makes it easy
to possibly miss an exception that may be thrown.  Yes that would catch MFC
exceptions but what about a user exception or other exception.  What it
comes down to it seems is that ALL exceptions MUST be handled by an
appropriate handler (not catch(...)) otherwise an exception would leave
unfreed memory.  I've seen plenty of code with just a catch(...) handler and
it seems that is not a reasonable thing to do.

Quote:

>You can try to do

>try
>{
>    Do stuff
>}
>catch (CException* pEx)
>{
>    Handle exception
>    pEx->Delete();
>}

>Any exceptions that are thrown by MFC are derived from the CException, so
>code above will catch them. I guess it might not handle some low-level
>exceptions, like zero divide, overflow, etc., but you should try.


>>Is it generally considered bad to use catch(...) exception handlers?
>>It seems doing so can easily lead to memory leaks unless ALL other
>>exceptions are handled properly.

>>For example:

>>try
>>{
>>    throw new CException();

>>}
>>catch(...)
>>{

>>}

>>This will result in a memory leak. While this example is clear it gets
more
>>interesting when you call functions that may throw numerous exception
>types.
>>If I understand this correctly, you must have a catch handler for all
>>exception types and free all the memory, as you can not use a catch(...)
>>handler since you will lose the exception generated (and if it was
>allocated
>>on the heap there is a memory leak then.)

>>It would seem then that catch(...) should always rethrow the exception OR
>>terminate the program otherwise a memory leak may result, unless you are
>>absolutely sure that all other exceptions will be handled, so this would
>>REQUIRE catch handlers for all other exception type cases.  For the most
>>part in MFC this would probably just mean handling catch(CException *) but
>>some are not even CExceptions, and then if you have user defined
exceptions
>>you would have to catch those as well specifically or suffer a memory
leak.

>>Am I misunderstanding this, or is there some other method of handling this
>>properly.



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
IMHO, it is not a good practice to "always" catch the thrown exceptions
using the catch( ... ) statement.  Different exceptions needs different way
of freeing itself.  Although most of the exceptions are usually subclassed
from CException, this is not the case most of the time.  I, for one, uses an
ordinary bool variable to throw around in some function of mine just to
abort a specific loop.  One more thing, (...) doesn't provide any info on
the caught exception so the program cannot, in any way, free the exception
if it was preallocated.  Unless you don't really know what your trying to
catch, that's the time you'll be needing the (...) statement.  It's just a
matter of developing a good programming habit.  If this programs were
created by some of your co-employee/programmer where you are working with on
the same project, you better tell 'em to change it.

Goodluck
John


Quote:
>Is it generally considered bad to use catch(...) exception handlers?
>It seems doing so can easily lead to memory leaks unless ALL other
>exceptions are handled properly.

>For example:

>try
>{
>    throw new CException();

>}
>catch(...)
>{

>}

>This will result in a memory leak. While this example is clear it gets more
>interesting when you call functions that may throw numerous exception
types.
>If I understand this correctly, you must have a catch handler for all
>exception types and free all the memory, as you can not use a catch(...)
>handler since you will lose the exception generated (and if it was
allocated
>on the heap there is a memory leak then.)

>It would seem then that catch(...) should always rethrow the exception OR
>terminate the program otherwise a memory leak may result, unless you are
>absolutely sure that all other exceptions will be handled, so this would
>REQUIRE catch handlers for all other exception type cases.  For the most
>part in MFC this would probably just mean handling catch(CException *) but
>some are not even CExceptions, and then if you have user defined exceptions
>you would have to catch those as well specifically or suffer a memory leak.

>Am I misunderstanding this, or is there some other method of handling this
>properly.



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
No, just code in general that I've run across on the internet.  But I'd be
willing to bet that many people have some code that does this lying around.
The problem really is when people might decide to handle all exceptions with
a catch(...) rather than each individual one, and when the exception was
allocated.  It seems there should be a safer mechanism for dealing with
exceptions to make sure that allocated thrown exceptions get cleaned up
properly.

Quote:

>IMHO, it is not a good practice to "always" catch the thrown exceptions
>using the catch( ... ) statement.  Different exceptions needs different way
>of freeing itself.  Although most of the exceptions are usually subclassed
>from CException, this is not the case most of the time.  I, for one, uses
an
>ordinary bool variable to throw around in some function of mine just to
>abort a specific loop.  One more thing, (...) doesn't provide any info on
>the caught exception so the program cannot, in any way, free the exception
>if it was preallocated.  Unless you don't really know what your trying to
>catch, that's the time you'll be needing the (...) statement.  It's just a
>matter of developing a good programming habit.  If this programs were
>created by some of your co-employee/programmer where you are working with
on
>the same project, you better tell 'em to change it.

>Goodluck
>John



>>Is it generally considered bad to use catch(...) exception handlers?
>>It seems doing so can easily lead to memory leaks unless ALL other
>>exceptions are handled properly.

>>For example:

>>try
>>{
>>    throw new CException();

>>}
>>catch(...)
>>{

>>}

>>This will result in a memory leak. While this example is clear it gets
more
>>interesting when you call functions that may throw numerous exception
>types.
>>If I understand this correctly, you must have a catch handler for all
>>exception types and free all the memory, as you can not use a catch(...)
>>handler since you will lose the exception generated (and if it was
>allocated
>>on the heap there is a memory leak then.)

>>It would seem then that catch(...) should always rethrow the exception OR
>>terminate the program otherwise a memory leak may result, unless you are
>>absolutely sure that all other exceptions will be handled, so this would
>>REQUIRE catch handlers for all other exception type cases.  For the most
>>part in MFC this would probably just mean handling catch(CException *) but
>>some are not even CExceptions, and then if you have user defined
exceptions
>>you would have to catch those as well specifically or suffer a memory
leak.

>>Am I misunderstanding this, or is there some other method of handling this
>>properly.



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?

Quote:

>Does any of this ring a bell with
>anyone?

The following:

Quote:
>   try
>   {
>      throw;   // rethrow the last exception
>   }

tends to cause VC++ to double-destruct exception objects. See this message
for more:


--
Doug Harrison



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
A lot of responses so far. In a nutshell:

1) Don't ever use "new" to throw an exception
2) All objects should have appropriate destructors that clean up memory and
all other allocated resources, if any. If an exception is thrown, your
therefore guaranteed that no memory leaks within your control will occur.
You can't do anything about memory that's internally leaked by some API
unless you have the power to free the object you've been allocated by that
API in your own destructor (hence causing the internal memory to hopefully
be freed). If you can, do so.
3) ALWAYS include a catch (...) since you never know when an undocumented
exception will be thrown by some 3rd party code (Windows or anybody else).
4) NEVER, EVER allocate memory that isn't freed by some destructor. Using
"new" doesn't cut it if some exception can later occur and the memory will
not be freed by some destructor. Augment your use of "new" with the standard
template "auto_ptr" wherever required  (see this template for details).

That's just about all you'll ever need to know to prevent memory leaks.

Quote:

>Is it generally considered bad to use catch(...) exception handlers?
>It seems doing so can easily lead to memory leaks unless ALL other
>exceptions are handled properly.

>For example:

>try
>{
>    throw new CException();

>}
>catch(...)
>{

>}

>This will result in a memory leak. While this example is clear it gets more
>interesting when you call functions that may throw numerous exception
types.
>If I understand this correctly, you must have a catch handler for all
>exception types and free all the memory, as you can not use a catch(...)
>handler since you will lose the exception generated (and if it was
allocated
>on the heap there is a memory leak then.)

>It would seem then that catch(...) should always rethrow the exception OR
>terminate the program otherwise a memory leak may result, unless you are
>absolutely sure that all other exceptions will be handled, so this would
>REQUIRE catch handlers for all other exception type cases.  For the most
>part in MFC this would probably just mean handling catch(CException *) but
>some are not even CExceptions, and then if you have user defined exceptions
>you would have to catch those as well specifically or suffer a memory leak.

>Am I misunderstanding this, or is there some other method of handling this
>properly.



Sat, 09 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
You forgot the most important one, the one the question was about in the
first place.

When programming with MFC, ALWAYS use a
catch(CException *e)
{
    e->Delete();
    // Other exception code here

Quote:
}

before using a catch(...)
This is because if you don't handle MFC Exceptions (thrown by pointer) and
delete them, you WILL have a memory leak.

Vincent Minden

Quote:

>A lot of responses so far. In a nutshell:

>1) Don't ever use "new" to throw an exception
>2) All objects should have appropriate destructors that clean up memory and
>all other allocated resources, if any. If an exception is thrown, your
>therefore guaranteed that no memory leaks within your control will occur.
>You can't do anything about memory that's internally leaked by some API
>unless you have the power to free the object you've been allocated by that
>API in your own destructor (hence causing the internal memory to hopefully
>be freed). If you can, do so.
>3) ALWAYS include a catch (...) since you never know when an undocumented
>exception will be thrown by some 3rd party code (Windows or anybody else).
>4) NEVER, EVER allocate memory that isn't freed by some destructor. Using
>"new" doesn't cut it if some exception can later occur and the memory will
>not be freed by some destructor. Augment your use of "new" with the
standard
>template "auto_ptr" wherever required  (see this template for details).

>That's just about all you'll ever need to know to prevent memory leaks.


>>Is it generally considered bad to use catch(...) exception handlers?
>>It seems doing so can easily lead to memory leaks unless ALL other
>>exceptions are handled properly.

>>For example:

>>try
>>{
>>    throw new CException();

>>}
>>catch(...)
>>{

>>}

>>This will result in a memory leak. While this example is clear it gets
more
>>interesting when you call functions that may throw numerous exception
>types.
>>If I understand this correctly, you must have a catch handler for all
>>exception types and free all the memory, as you can not use a catch(...)
>>handler since you will lose the exception generated (and if it was
>allocated
>>on the heap there is a memory leak then.)

>>It would seem then that catch(...) should always rethrow the exception OR
>>terminate the program otherwise a memory leak may result, unless you are
>>absolutely sure that all other exceptions will be handled, so this would
>>REQUIRE catch handlers for all other exception type cases.  For the most
>>part in MFC this would probably just mean handling catch(CException *) but
>>some are not even CExceptions, and then if you have user defined
exceptions
>>you would have to catch those as well specifically or suffer a memory
leak.

>>Am I misunderstanding this, or is there some other method of handling this
>>properly.



Sun, 10 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
Only because MFC violates rule #1, necessitating you heed rule #2.


Quote:
>You forgot the most important one, the one the question was about in the
>first place.

>When programming with MFC, ALWAYS use a
>catch(CException *e)
>{
>    e->Delete();
>    // Other exception code here
>}

>before using a catch(...)
>This is because if you don't handle MFC Exceptions (thrown by pointer) and
>delete them, you WILL have a memory leak.

>Vincent Minden


>>A lot of responses so far. In a nutshell:

>>1) Don't ever use "new" to throw an exception
>>2) All objects should have appropriate destructors that clean up memory
and
>>all other allocated resources, if any. If an exception is thrown, your
>>therefore guaranteed that no memory leaks within your control will occur.
>>You can't do anything about memory that's internally leaked by some API
>>unless you have the power to free the object you've been allocated by that
>>API in your own destructor (hence causing the internal memory to hopefully
>>be freed). If you can, do so.
>>3) ALWAYS include a catch (...) since you never know when an undocumented
>>exception will be thrown by some 3rd party code (Windows or anybody else).
>>4) NEVER, EVER allocate memory that isn't freed by some destructor. Using
>>"new" doesn't cut it if some exception can later occur and the memory will
>>not be freed by some destructor. Augment your use of "new" with the
>standard
>>template "auto_ptr" wherever required  (see this template for details).

>>That's just about all you'll ever need to know to prevent memory leaks.


>>>Is it generally considered bad to use catch(...) exception handlers?
>>>It seems doing so can easily lead to memory leaks unless ALL other
>>>exceptions are handled properly.

>>>For example:

>>>try
>>>{
>>>    throw new CException();

>>>}
>>>catch(...)
>>>{

>>>}

>>>This will result in a memory leak. While this example is clear it gets
>more
>>>interesting when you call functions that may throw numerous exception
>>types.
>>>If I understand this correctly, you must have a catch handler for all
>>>exception types and free all the memory, as you can not use a catch(...)
>>>handler since you will lose the exception generated (and if it was
>>allocated
>>>on the heap there is a memory leak then.)

>>>It would seem then that catch(...) should always rethrow the exception OR
>>>terminate the program otherwise a memory leak may result, unless you are
>>>absolutely sure that all other exceptions will be handled, so this would
>>>REQUIRE catch handlers for all other exception type cases.  For the most
>>>part in MFC this would probably just mean handling catch(CException *)
but
>>>some are not even CExceptions, and then if you have user defined
>exceptions
>>>you would have to catch those as well specifically or suffer a memory
>leak.

>>>Am I misunderstanding this, or is there some other method of handling
this
>>>properly.



Sun, 10 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
Well true, but the question was about exceptions in MFC in the first place,
not about how exceptions should be used in general.  We all know that
Microsoft doesn't always follow good programming rules.

So while your rules are great for general programming, I felt that they
needed to explicitly address the MFC issue since that was the original
question.

Vincent Minden

Quote:

>Only because MFC violates rule #1, necessitating you heed rule #2.



>>You forgot the most important one, the one the question was about in the
>>first place.

>>When programming with MFC, ALWAYS use a
>>catch(CException *e)
>>{
>>    e->Delete();
>>    // Other exception code here
>>}

>>before using a catch(...)
>>This is because if you don't handle MFC Exceptions (thrown by pointer) and
>>delete them, you WILL have a memory leak.

>>Vincent Minden


>>>A lot of responses so far. In a nutshell:

>>>1) Don't ever use "new" to throw an exception
>>>2) All objects should have appropriate destructors that clean up memory
>and
>>>all other allocated resources, if any. If an exception is thrown, your
>>>therefore guaranteed that no memory leaks within your control will occur.
>>>You can't do anything about memory that's internally leaked by some API
>>>unless you have the power to free the object you've been allocated by
that
>>>API in your own destructor (hence causing the internal memory to
hopefully
>>>be freed). If you can, do so.
>>>3) ALWAYS include a catch (...) since you never know when an undocumented
>>>exception will be thrown by some 3rd party code (Windows or anybody
else).
>>>4) NEVER, EVER allocate memory that isn't freed by some destructor. Using
>>>"new" doesn't cut it if some exception can later occur and the memory
will
>>>not be freed by some destructor. Augment your use of "new" with the
>>standard
>>>template "auto_ptr" wherever required  (see this template for details).

>>>That's just about all you'll ever need to know to prevent memory leaks.


>>>>Is it generally considered bad to use catch(...) exception handlers?
>>>>It seems doing so can easily lead to memory leaks unless ALL other
>>>>exceptions are handled properly.

>>>>For example:

>>>>try
>>>>{
>>>>    throw new CException();

>>>>}
>>>>catch(...)
>>>>{

>>>>}

>>>>This will result in a memory leak. While this example is clear it gets
>>more
>>>>interesting when you call functions that may throw numerous exception
>>>types.
>>>>If I understand this correctly, you must have a catch handler for all
>>>>exception types and free all the memory, as you can not use a catch(...)
>>>>handler since you will lose the exception generated (and if it was
>>>allocated
>>>>on the heap there is a memory leak then.)

>>>>It would seem then that catch(...) should always rethrow the exception
OR
>>>>terminate the program otherwise a memory leak may result, unless you are
>>>>absolutely sure that all other exceptions will be handled, so this would
>>>>REQUIRE catch handlers for all other exception type cases.  For the most
>>>>part in MFC this would probably just mean handling catch(CException *)
>but
>>>>some are not even CExceptions, and then if you have user defined
>>exceptions
>>>>you would have to catch those as well specifically or suffer a memory
>>leak.

>>>>Am I misunderstanding this, or is there some other method of handling
>this
>>>>properly.



Sun, 10 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
Also you MUST catch CException * everywhere instead of just catch(...)
otherwise a memory leak will occurr it seems, since MFC throws pointers
instead of objects.

Quote:

>A lot of responses so far. In a nutshell:

>1) Don't ever use "new" to throw an exception
>2) All objects should have appropriate destructors that clean up memory and
>all other allocated resources, if any. If an exception is thrown, your
>therefore guaranteed that no memory leaks within your control will occur.
>You can't do anything about memory that's internally leaked by some API
>unless you have the power to free the object you've been allocated by that
>API in your own destructor (hence causing the internal memory to hopefully
>be freed). If you can, do so.
>3) ALWAYS include a catch (...) since you never know when an undocumented
>exception will be thrown by some 3rd party code (Windows or anybody else).
>4) NEVER, EVER allocate memory that isn't freed by some destructor. Using
>"new" doesn't cut it if some exception can later occur and the memory will
>not be freed by some destructor. Augment your use of "new" with the
standard
>template "auto_ptr" wherever required  (see this template for details).

>That's just about all you'll ever need to know to prevent memory leaks.


>>Is it generally considered bad to use catch(...) exception handlers?
>>It seems doing so can easily lead to memory leaks unless ALL other
>>exceptions are handled properly.

>>For example:

>>try
>>{
>>    throw new CException();

>>}
>>catch(...)
>>{

>>}

>>This will result in a memory leak. While this example is clear it gets
more
>>interesting when you call functions that may throw numerous exception
>types.
>>If I understand this correctly, you must have a catch handler for all
>>exception types and free all the memory, as you can not use a catch(...)
>>handler since you will lose the exception generated (and if it was
>allocated
>>on the heap there is a memory leak then.)

>>It would seem then that catch(...) should always rethrow the exception OR
>>terminate the program otherwise a memory leak may result, unless you are
>>absolutely sure that all other exceptions will be handled, so this would
>>REQUIRE catch handlers for all other exception type cases.  For the most
>>part in MFC this would probably just mean handling catch(CException *) but
>>some are not even CExceptions, and then if you have user defined
exceptions
>>you would have to catch those as well specifically or suffer a memory
leak.

>>Am I misunderstanding this, or is there some other method of handling this
>>properly.



Sun, 10 Jun 2001 03:00:00 GMT  
 C++/MFC and exceptions- catch(...)=bad?
Thanks everyone for the great explanations!

Quote:

>Is it generally considered bad to use catch(...) exception handlers?
>It seems doing so can easily lead to memory leaks unless ALL other
>exceptions are handled properly.

>For example:

>try
>{
>    throw new CException();

>}
>catch(...)
>{

>}

>This will result in a memory leak. While this example is clear it gets more
>interesting when you call functions that may throw numerous exception
types.
>If I understand this correctly, you must have a catch handler for all
>exception types and free all the memory, as you can not use a catch(...)
>handler since you will lose the exception generated (and if it was
allocated
>on the heap there is a memory leak then.)

>It would seem then that catch(...) should always rethrow the exception OR
>terminate the program otherwise a memory leak may result, unless you are
>absolutely sure that all other exceptions will be handled, so this would
>REQUIRE catch handlers for all other exception type cases.  For the most
>part in MFC this would probably just mean handling catch(CException *) but
>some are not even CExceptions, and then if you have user defined exceptions
>you would have to catch those as well specifically or suffer a memory leak.

>Am I misunderstanding this, or is there some other method of handling this
>properly.



Sun, 10 Jun 2001 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Catching Win32 exceptions with a C++ catch-block

2. Catching hardware exceptions using C++ exceptions

3. Catching SEC Exceptions as C++ Exceptions

4. C++ exceptions and de-referencing bad pointers

5. Catching unhandled exceptions in MFC DLL

6. Catching Win32/MFC Exceptions in eVC++

7. No way to catch exceptions thrown from MFC

8. catching Win32 API exceptions in C++

9. Howto catch Win32 exceptions in C++?

10. catching math exceptions with C++

11. Catching Structure Exceptions in C++ EH

12. Unable to catch exception thrown from ActiveX control in an MFC client

 

 
Powered by phpBB® Forum Software