Exception Handling in C++
-
Which of the three uses do you disagree with? The first use (
catch(...)at the end of main) is only when every other remedial action has failed and the program's going to crash anyway. If you have other base exceptions or exceptions that aren't derived fromstd::exceptionfeel free to add catches for them at the top level. Another type is where something throws in a destructor. You can't let exceptions come out of a destructor, std::terminate will end up being called in most cases. So the program's going to crash - you might as well handle it and tell the user that something's gone wrong then bail out cleanly. A final example is where you don't know where you're throwing. If you have a C interface there's no guarentee that something on the other side knows what to do with it. So catch the exception and translate it to an error code - even if the error code is "Buggered if I know what went wrong in here mate..." which should be translated by the caller into stick up an error message and bail out of the program. One final point - you shouldn't need to manually clean up resources in the face of an exception. We're talking C++ here and not Java (and even then you've gotfinally, notcatch( ... )). The general idiom with C++ is to handle cleanup of resources using RAII, don't do it manually 'cause you're bound to miss something. Cheers, AshOn the issue of a
catch (...)in main as follows (I also have objections on other grounds, but we'll address one issue at a time):#include "stdafx.h"
#include <tchar.h>
#include <iostream>
#include <stdexcept>using namespace std;
class MyException : public runtime_error
{
public:
MyException(const char *pMsg) : runtime_error(pMsg) {}
};void SomeFunction()
{
throw MyException("SomeFunction()");
}int _tmain(int argc, _TCHAR* argv[])
{
try
{
SomeFunction(); // Unexpected exception thrown in here (assume it's deeply nested).
}
catch (...)
{
cerr << "Caught exception..." << endl;
}return 0;}
All the error information you get from the unexpected event is the following message:
Caught exception...
If the
catch (...)is removed a crash dump is generated and the stack extracted from it (using WinDBG) looks as follows:0:000> .ecxr
eax=00000000 ebx=0024f2d4 ecx=00000000 edx=0008dcd8 esi=770a030c edi=011915e3
eip=742dbb47 esp=0024f1e8 ebp=0024f214 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
msvcr90!terminate+0x33:
742dbb47 e879100100 call msvcr90!__SEH_epilog4 (742ecbc5)
0:000> kvn 1000ChildEBP RetAddr Args to Child
00 0024f214 0119161f 0024f2a4 77009d57 0024f2d4 msvcr90!terminate+0x33 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\hooks.cpp @ 130]
01 0024f21c 77009d57 0024f2d4 b21db5fb 00000000 Console!__CxxUnhandledExceptionFilter+0x3c (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\unhandld.cpp @ 72]
02 0024f2a4 77b10727 0024f2d4 77b10604 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
03 0024f2ac 77b10604 00000000 0024f894 77acc3d0 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
04 0024f2c0 77b104a9 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
05 0024f2e8 77af87b9 fffffffe 0024f884 0024f424 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
06 0024f30c 77af878b 0024f3d4 0024f884 0024f424 ntdll!ExecuteHandler2+0x26
07 0024f3bc 77ab010f 0024f3d4 0024f424 0024f3d4 ntdll!ExecuteHandler+0x24
08 0024f3bc 772bb727 0024f3d4 0024f424 0024f3d4 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0024f424)
09 0024f75c 742ddbf9 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 (FPO: [4,20,0])
0a 0024f794 0119106a 0024f7b4 01192460 b2 -
Can anyone point me to any open source application using exception handling? I have never used EH myself nor ever felt the need to use it. Just wondering what and when is the right use for it? I want to see how other ppl use exception handling in their code and how does it make their program robust? one good thing about EH is to quickly exit from deeply nested hierarchy. but how do experts use it? How often do you use EH in your code?
One open source project whose author knows about try..catch blocks is this: 1. http://freshmeat.net/projects/ecasound[^] check ecasound-2.7.1\ecasound-2.7.1\Documentation\programmers_guide\ecasound_programmers_guide.txt (use of EH is very minimal here ut at least it exists) I will add more projects as and when I find them... have installed a catch(...) for all future source code checks. :laugh:
modified on Tuesday, June 29, 2010 9:21 AM
-
On the issue of a
catch (...)in main as follows (I also have objections on other grounds, but we'll address one issue at a time):#include "stdafx.h"
#include <tchar.h>
#include <iostream>
#include <stdexcept>using namespace std;
class MyException : public runtime_error
{
public:
MyException(const char *pMsg) : runtime_error(pMsg) {}
};void SomeFunction()
{
throw MyException("SomeFunction()");
}int _tmain(int argc, _TCHAR* argv[])
{
try
{
SomeFunction(); // Unexpected exception thrown in here (assume it's deeply nested).
}
catch (...)
{
cerr << "Caught exception..." << endl;
}return 0;}
All the error information you get from the unexpected event is the following message:
Caught exception...
If the
catch (...)is removed a crash dump is generated and the stack extracted from it (using WinDBG) looks as follows:0:000> .ecxr
eax=00000000 ebx=0024f2d4 ecx=00000000 edx=0008dcd8 esi=770a030c edi=011915e3
eip=742dbb47 esp=0024f1e8 ebp=0024f214 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
msvcr90!terminate+0x33:
742dbb47 e879100100 call msvcr90!__SEH_epilog4 (742ecbc5)
0:000> kvn 1000ChildEBP RetAddr Args to Child
00 0024f214 0119161f 0024f2a4 77009d57 0024f2d4 msvcr90!terminate+0x33 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\hooks.cpp @ 130]
01 0024f21c 77009d57 0024f2d4 b21db5fb 00000000 Console!__CxxUnhandledExceptionFilter+0x3c (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\unhandld.cpp @ 72]
02 0024f2a4 77b10727 0024f2d4 77b10604 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
03 0024f2ac 77b10604 00000000 0024f894 77acc3d0 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
04 0024f2c0 77b104a9 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
05 0024f2e8 77af87b9 fffffffe 0024f884 0024f424 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
06 0024f30c 77af878b 0024f3d4 0024f884 0024f424 ntdll!ExecuteHandler2+0x26
07 0024f3bc 77ab010f 0024f3d4 0024f424 0024f3d4 ntdll!ExecuteHandler+0x24
08 0024f3bc 772bb727 0024f3d4 0024f424 0024f3d4 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0024f424)
09 0024f75c 742ddbf9 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 (FPO: [4,20,0])
0a 0024f794 0119106a 0024f7b4 01192460 b2thanks for the detailed reply but for a lay user, crash is just an act of cheating by the application. if a software crashes 2-3 times, I normally uninstall it (except the windows OS and ibm rational clearcase coz' i do not hv options in these 2 cases) If one use catch all in main and then give some kind of error message to the user, that this module has failed. we're sorry. our chipmunks are running to solve your problem, then it is better. and regarding your stack trace, yes it can be very helpful if you can get the log but I dont know much about it. I think there are ways using SEH to get stack trace etc. anyway, you made a good point :))
-
On the issue of a
catch (...)in main as follows (I also have objections on other grounds, but we'll address one issue at a time):#include "stdafx.h"
#include <tchar.h>
#include <iostream>
#include <stdexcept>using namespace std;
class MyException : public runtime_error
{
public:
MyException(const char *pMsg) : runtime_error(pMsg) {}
};void SomeFunction()
{
throw MyException("SomeFunction()");
}int _tmain(int argc, _TCHAR* argv[])
{
try
{
SomeFunction(); // Unexpected exception thrown in here (assume it's deeply nested).
}
catch (...)
{
cerr << "Caught exception..." << endl;
}return 0;}
All the error information you get from the unexpected event is the following message:
Caught exception...
If the
catch (...)is removed a crash dump is generated and the stack extracted from it (using WinDBG) looks as follows:0:000> .ecxr
eax=00000000 ebx=0024f2d4 ecx=00000000 edx=0008dcd8 esi=770a030c edi=011915e3
eip=742dbb47 esp=0024f1e8 ebp=0024f214 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
msvcr90!terminate+0x33:
742dbb47 e879100100 call msvcr90!__SEH_epilog4 (742ecbc5)
0:000> kvn 1000ChildEBP RetAddr Args to Child
00 0024f214 0119161f 0024f2a4 77009d57 0024f2d4 msvcr90!terminate+0x33 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\hooks.cpp @ 130]
01 0024f21c 77009d57 0024f2d4 b21db5fb 00000000 Console!__CxxUnhandledExceptionFilter+0x3c (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\unhandld.cpp @ 72]
02 0024f2a4 77b10727 0024f2d4 77b10604 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
03 0024f2ac 77b10604 00000000 0024f894 77acc3d0 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
04 0024f2c0 77b104a9 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
05 0024f2e8 77af87b9 fffffffe 0024f884 0024f424 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
06 0024f30c 77af878b 0024f3d4 0024f884 0024f424 ntdll!ExecuteHandler2+0x26
07 0024f3bc 77ab010f 0024f3d4 0024f424 0024f3d4 ntdll!ExecuteHandler+0x24
08 0024f3bc 772bb727 0024f3d4 0024f424 0024f3d4 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0024f424)
09 0024f75c 742ddbf9 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 (FPO: [4,20,0])
0a 0024f794 0119106a 0024f7b4 01192460 b2 -
This is a complete strawman - the exception you're throwing is derived from std::exception so the first catch clause I wrote would have caught it.
Aescleal wrote:
This is a complete strawman - the exception you're throwing is derived from std::exception so the first catch clause I wrote would have caught it.
You seem to be missing the point. The choice of exception was arbitrary, the point is that it's not expected. Sure the first
catchin your code would have caught it, but there is no such beast in the code I posted. My code is different to yours; you seem to be misrepresenting my argument. Who's augment is the straw man? You asked me to elaborate on my position and I did: instead of the user getting a generic error message (of no use to anyone) I get a dump file. I prefer the latter.Steve
-
thanks for the detailed reply but for a lay user, crash is just an act of cheating by the application. if a software crashes 2-3 times, I normally uninstall it (except the windows OS and ibm rational clearcase coz' i do not hv options in these 2 cases) If one use catch all in main and then give some kind of error message to the user, that this module has failed. we're sorry. our chipmunks are running to solve your problem, then it is better. and regarding your stack trace, yes it can be very helpful if you can get the log but I dont know much about it. I think there are ways using SEH to get stack trace etc. anyway, you made a good point :))
Sure, if it crashes frequently you ditch it. Nothing unusual about you so far. What do you do if it doesn't crash per se, but instead fails with a generic error message just as frequently? I suspect the same. I say let it crash, suck down the crash dumps and fix the problem.
Steve
-
Sure, if it crashes frequently you ditch it. Nothing unusual about you so far. What do you do if it doesn't crash per se, but instead fails with a generic error message just as frequently? I suspect the same. I say let it crash, suck down the crash dumps and fix the problem.
Steve
yes, you are right but correct me if I am wrong. Windows 7 seems to be using lot of exception handling and displaying message about why it crashed with what error code. eg. in windows xp, if your explorer crashes, you get a message like "An unhandled win32 exception occured in explorer.exe".. but in windows 7, i hope you have observed it's different. they give you error message etc. You can argue that even information in latter case is not very helpful but in my experience, it is less annoying. same is the case with world's best browser ;) opera. whenever it crashes (once a year or two maybe.. to be honest, opera never crashed before v9. after that i think lot of advancements have made it complex, so it has started crashing once every 3 months or so), an option is provided to restart the browser, along with sending crash dump to opera where it is analyzed and the reason for crash is displayed to the user. In nutshell, exception handling when done properly can make your application more polite and responsible. If you are not handling exceptions and your application crashes without a hint, how the user will know which dump files to send to which address and in fact, will they ever bother to do it themselves? ;P
-
yes, you are right but correct me if I am wrong. Windows 7 seems to be using lot of exception handling and displaying message about why it crashed with what error code. eg. in windows xp, if your explorer crashes, you get a message like "An unhandled win32 exception occured in explorer.exe".. but in windows 7, i hope you have observed it's different. they give you error message etc. You can argue that even information in latter case is not very helpful but in my experience, it is less annoying. same is the case with world's best browser ;) opera. whenever it crashes (once a year or two maybe.. to be honest, opera never crashed before v9. after that i think lot of advancements have made it complex, so it has started crashing once every 3 months or so), an option is provided to restart the browser, along with sending crash dump to opera where it is analyzed and the reason for crash is displayed to the user. In nutshell, exception handling when done properly can make your application more polite and responsible. If you are not handling exceptions and your application crashes without a hint, how the user will know which dump files to send to which address and in fact, will they ever bother to do it themselves? ;P
Windows Error Reporting[^] allows you to publish a solution for a particular stack (it classifies crashes). When you do this and a user gets that particular crash, they get the message you associated with it. This allows you to tell the user what's wrong and what to do about fixing it. The dumps are send automatically (the user has to agree). Sure you could use some custom error reporting framework as some products do, or you could just let it crash and use the one that comes with the OS.
Steve
-
Windows Error Reporting[^] allows you to publish a solution for a particular stack (it classifies crashes). When you do this and a user gets that particular crash, they get the message you associated with it. This allows you to tell the user what's wrong and what to do about fixing it. The dumps are send automatically (the user has to agree). Sure you could use some custom error reporting framework as some products do, or you could just let it crash and use the one that comes with the OS.
Steve
yes, it is a good alternative. One of the requirements of using it is that "You must have administrative privileges on the machine you are using". That should not be a problem in majority of cases though. second thing is it is "windows" specific. Exception handling is platform neutral. third thing is I never send data to microsoft website. however, if any of my fav. app crashes, i do send the crash dump to them. thanks for the info. btw.
-
On the issue of a
catch (...)in main as follows (I also have objections on other grounds, but we'll address one issue at a time):#include "stdafx.h"
#include <tchar.h>
#include <iostream>
#include <stdexcept>using namespace std;
class MyException : public runtime_error
{
public:
MyException(const char *pMsg) : runtime_error(pMsg) {}
};void SomeFunction()
{
throw MyException("SomeFunction()");
}int _tmain(int argc, _TCHAR* argv[])
{
try
{
SomeFunction(); // Unexpected exception thrown in here (assume it's deeply nested).
}
catch (...)
{
cerr << "Caught exception..." << endl;
}return 0;}
All the error information you get from the unexpected event is the following message:
Caught exception...
If the
catch (...)is removed a crash dump is generated and the stack extracted from it (using WinDBG) looks as follows:0:000> .ecxr
eax=00000000 ebx=0024f2d4 ecx=00000000 edx=0008dcd8 esi=770a030c edi=011915e3
eip=742dbb47 esp=0024f1e8 ebp=0024f214 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
msvcr90!terminate+0x33:
742dbb47 e879100100 call msvcr90!__SEH_epilog4 (742ecbc5)
0:000> kvn 1000ChildEBP RetAddr Args to Child
00 0024f214 0119161f 0024f2a4 77009d57 0024f2d4 msvcr90!terminate+0x33 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\hooks.cpp @ 130]
01 0024f21c 77009d57 0024f2d4 b21db5fb 00000000 Console!__CxxUnhandledExceptionFilter+0x3c (FPO: [Non-Fpo]) (CONV: stdcall) [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\unhandld.cpp @ 72]
02 0024f2a4 77b10727 0024f2d4 77b10604 00000000 kernel32!UnhandledExceptionFilter+0x127 (FPO: [SEH])
03 0024f2ac 77b10604 00000000 0024f894 77acc3d0 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
04 0024f2c0 77b104a9 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
05 0024f2e8 77af87b9 fffffffe 0024f884 0024f424 ntdll!_except_handler4+0x8e (FPO: [4,5,4])
06 0024f30c 77af878b 0024f3d4 0024f884 0024f424 ntdll!ExecuteHandler2+0x26
07 0024f3bc 77ab010f 0024f3d4 0024f424 0024f3d4 ntdll!ExecuteHandler+0x24
08 0024f3bc 772bb727 0024f3d4 0024f424 0024f3d4 ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0024f424)
09 0024f75c 742ddbf9 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58 (FPO: [4,20,0])
0a 0024f794 0119106a 0024f7b4 01192460 b2 -
yes, it is a good alternative. One of the requirements of using it is that "You must have administrative privileges on the machine you are using". That should not be a problem in majority of cases though. second thing is it is "windows" specific. Exception handling is platform neutral. third thing is I never send data to microsoft website. however, if any of my fav. app crashes, i do send the crash dump to them. thanks for the info. btw.
theCPkid wrote:
One of the requirements of using it is that "You must have administrative privileges on the machine you are using". That should not be a problem in majority of cases though.
I'm not sure what you're referring to here. The user doesn't need to have administrative privileges to submit a dump file.
theCPkid wrote:
second thing is it is "windows" specific. Exception handling is platform neutral.
Yeah, Windows Error Reporting is certainly Windows specific. That said this message board is primarily about Windows. The general principle of crashing as close to the initiating fault still applies.
Steve