try catch not working
-
My very large app was shipped to a customer and as you might guess it failed. My code has lots of try catches in it and I though it strange that it failed with no exception traps shown in the log. After trying to insert some deliberate exceptions I found that the exception traps are not working at all. To test what was going on I created a console app: int _tmain(int argc, _TCHAR* argv[]) { printf("Start\n"); try { int *pWord=NULL; *pWord=999; } catch(...) { printf("Error was caught\n"); } printf("Stop\n"); return 0; } This should display Start Error was caught Stop But it actually displays Start .. the the MS crash dialog pops up. Does anyone know why my exception traps have been disabled. Richard.
Hell I thought it was funny .....
-
My very large app was shipped to a customer and as you might guess it failed. My code has lots of try catches in it and I though it strange that it failed with no exception traps shown in the log. After trying to insert some deliberate exceptions I found that the exception traps are not working at all. To test what was going on I created a console app: int _tmain(int argc, _TCHAR* argv[]) { printf("Start\n"); try { int *pWord=NULL; *pWord=999; } catch(...) { printf("Error was caught\n"); } printf("Stop\n"); return 0; } This should display Start Error was caught Stop But it actually displays Start .. the the MS crash dialog pops up. Does anyone know why my exception traps have been disabled. Richard.
Hell I thought it was funny .....
All is working as it should on a standard compliant C++ compiler. Low level exceptions are not meant to be caught by C++
catchblocks; only C++ exceptions thrown by the C++throwkeyword are. MSVC6 was buggy in this area and such exceptions could be caught by this construct. This bug was fixed in later versions. The "old" (non standard) behaviour can be enabled via the /EHa[^] compiler switch. Alternatively you can use SEH[^] to catch low level exceptions; be warned however that this is specific to the Windows platform and doesn't unwind the stack.Steve
-
All is working as it should on a standard compliant C++ compiler. Low level exceptions are not meant to be caught by C++
catchblocks; only C++ exceptions thrown by the C++throwkeyword are. MSVC6 was buggy in this area and such exceptions could be caught by this construct. This bug was fixed in later versions. The "old" (non standard) behaviour can be enabled via the /EHa[^] compiler switch. Alternatively you can use SEH[^] to catch low level exceptions; be warned however that this is specific to the Windows platform and doesn't unwind the stack.Steve
-
All is working as it should on a standard compliant C++ compiler. Low level exceptions are not meant to be caught by C++
catchblocks; only C++ exceptions thrown by the C++throwkeyword are. MSVC6 was buggy in this area and such exceptions could be caught by this construct. This bug was fixed in later versions. The "old" (non standard) behaviour can be enabled via the /EHa[^] compiler switch. Alternatively you can use SEH[^] to catch low level exceptions; be warned however that this is specific to the Windows platform and doesn't unwind the stack.Steve
So I made the changes and it made no difference to the problem. However, I managed to connect the debugger and what I've found is frightening. The problem is ocurring because I'm passing an invalid parameter to localtime_s but rather than reporting any error or throwing an exception it is directly calling: _invoke_watson(pszExpression, pszFunction, pszFile, nLine, pReserved); So msvcrt80.dll directly invokes DrWatson rather than throwing an error for you to catch. Now looking at their code I can see that in order to catch invald parameters in my code I'm going to have to add an invalid parameter handler into it. This seems strange to me, surly rather than calling DrWatson, it should throw an exception or even return the error that the docs say it will return for an invalid value.
Hell I thought it was funny .....
-
My very large app was shipped to a customer and as you might guess it failed. My code has lots of try catches in it and I though it strange that it failed with no exception traps shown in the log. After trying to insert some deliberate exceptions I found that the exception traps are not working at all. To test what was going on I created a console app: int _tmain(int argc, _TCHAR* argv[]) { printf("Start\n"); try { int *pWord=NULL; *pWord=999; } catch(...) { printf("Error was caught\n"); } printf("Stop\n"); return 0; } This should display Start Error was caught Stop But it actually displays Start .. the the MS crash dialog pops up. Does anyone know why my exception traps have been disabled. Richard.
Hell I thought it was funny .....
null pointer or access violation exceptions are not treated as C++ exceptions but as SEH exceptions. You cannot catch SEH exceptions using the try catch block, you need to use a __try, __except block instead. There is away of unifying the two different exception handling mechanisms. Search for SEH on codeproject and you should find an article that describes how to do this.
-
So I made the changes and it made no difference to the problem. However, I managed to connect the debugger and what I've found is frightening. The problem is ocurring because I'm passing an invalid parameter to localtime_s but rather than reporting any error or throwing an exception it is directly calling: _invoke_watson(pszExpression, pszFunction, pszFile, nLine, pReserved); So msvcrt80.dll directly invokes DrWatson rather than throwing an error for you to catch. Now looking at their code I can see that in order to catch invald parameters in my code I'm going to have to add an invalid parameter handler into it. This seems strange to me, surly rather than calling DrWatson, it should throw an exception or even return the error that the docs say it will return for an invalid value.
Hell I thought it was funny .....
I don't generally approve of catching such exceptions (access violations). There are exceptions (not the programming type) – such as in low level code – but in general littering code with “catch alls” just makes debugging hard and postmortem debugging near impossible. A good rule when using exceptions is this: only catch what you expect can be thrown if the program is functioning normally. Breaking this rule can make you wish you never heard of exception handling. For example, if you get an access violation while building a doubly linked list you crash and the debugger or Dr.Watson dump is at the problem point; if the exception is caught the program continues with a corrupted list and if your lucky a crash occurs some time later and you’re left tearing you hair out trying to find the source of the corruption; if you’re unlucky the program doesn’t crash at all but just doesn’t work properly.
Steve