Hello
I was wondering this.
Does a try catch, catch a 0xC0000005 error, and the app can continue running after it occured?
thanks
Printable View
Hello
I was wondering this.
Does a try catch, catch a 0xC0000005 error, and the app can continue running after it occured?
thanks
No. Try/catch is not designed for unexpected situations---it's designed for cases where you *know* there's a possibility of error (like a network connection not being established) and want to be able to handle it.
Really, catching an exception isn't that different from checking a return code. It's just a different approach to the problem which is harder to ignore during development.
Say what ? If it is not designed to handle unexpected errors, then what is it supposed to handle ?Quote:
No. Try/catch is not designed for unexpected situations
This code shows the user nothing and will continue to execute the rest of the code.Code:try
{
// this will trigger a crash
((CWnd*)12345678)->ShowWindow (SW_SHOW);
}
catch (...)
{
// do nothing
}
Really, I have to disagree 200% with this statement. Using a try/catch as a pseudo return code is HORRIBLE !Quote:
Really, catching an exception isn't that different from checking a return code. It's just a different approach to the problem which is harder to ignore during development.
I'll try Skizmo's approach and see if it works, i'll reply in a moment
In C++, try/catch is only possible if a C++ throw has occurred. The "throw" has to eitherQuote:
Originally Posted by ProgrammerC++
1) come from your own app (your own app does a "throw")
2) the C++ library (for example, std::vector::at() throws an exception, as well as "operator new" if there is a problem)
3) Some other library does a "throw".
If no module "throws" when a 0xC0000005 occurs, then no, try/catch won't do anything to help you.
Regards,
Paul McKenzie
I'll agree it's horrible, which is why I've been extremely light on my exception use so far. That's one area of C++ I haven't delved into in any detail yet. As I see it, throwing an exception usually means something happened that really shouldn't have happened if the code were correct.Quote:
Originally Posted by Skizmo
The one place where exceptions seem like the natural way to go to indicate an error is in a constructor, although of course you have the option of instead giving the object a failure state (like the stream classes).
However, I was under the impression that a catch statement couldn't do anything unless it had a corresponding throw somewhere.
Skizmo's code doesnt do the trick unfortunately
Guess there's no way to continue if a 0xC0000005 occurs :\
If your code were correct it would never occur, though.Quote:
Originally Posted by ProgrammerC++
I thought I'd point out that in Visual Studio (2008, probably 2005) if you enable the SEH option (/EHa), then Skizmo's code actually does work.
It's not the default "exceptions" mode in VSC++
Set a breakpoint inside the handler, the catch is made like you'd expected.
You might also attempt the older structured exception handling MS once used (__try/__except/__finally), but I think EHa wraps the concepts into C++ exceptions - not entirely sure if everything is caught, but the 0xC0000005 was caught, and execution continued in my short test example.
Even if that works via the C++ exception mechanism, it's important to note that Structured Exceptions are a Microsoft extension and are not standard C++.
And that anyway, *** lindley pointed out, having such an exception means that the code is not correct... ;)
True, but then a "0xC0000005" error isn't a portable notion either.
In most situations there is a way to route what is essentially OS or platform exceptions into the C++ exceptions mechanism, if by no other means that a library meant to offer the service.
We often need to deal with the marriage of C++/operating system/platform.
Another example of this setting:
In the default setting this fires off a 0xC0000094 exception, integer division by zero.Code:
int z=5;
int r=0;
int d = 0;
try
{
d = z / r;
}
catch(...)
{
}
With /EHa enabled, the exception is caught.
This latter one may be more controversial, if useful, because it goes counter to C++ specification (not just outside the definition).
With /EHa enabled, it does indeed work. Thanks
And it's not really my code, it's some ODBC functions crashing at random times (SQLDirectConnect() & SQLFreeHandle())
I'm not familiar with that package, but there's a better-than-average chance that the problem is with your usage of it, even if the crash occurs within the package itself. Most nontrivial libraries you find on the internet are sufficiently used that any bug so obvious would have been squelched long before you encountered it.
I second Lindley's point.
Even if SEH exceptions can get things working, it may be a kludge instead of a solution.
There could be side effects, too - mild, probably, but consider the integer divide by zero example. Say you had code which occasionally did encounter a divide by zero error (it would have crashed before, but say this happened only occasionally during development and you hadn't gotten around to dealing with it).
Well, turning on SEH, this would now 'catch' on an enclosing (...) exception spec, possibly higher up than you expect, and the results might mask a divide by zero with some really odd behavior.
Just pointing it out....it takes some care to really understand what SEH is enabling here, so you get what you're expecting.
The other pitfall is that you might get accustomed to it, then need to port code to Linux where it won't work.
That's Lindley's point from earlier - it's non-standard routing of CPU and OS exceptions, but it can be put to good use sometimes.
As a third-party library developer, I have to say this --Quote:
Originally Posted by ProgrammerC++
unless you can come up with a very simple example that demonstrates the error, then it will always be "your code" that is the cause of the crashes. You could be calling these functions out of sequence, on invalid handles, or you may have corrupted the heap in some way, etc.
The people that work on these libraries make all the effort to stamp out any bugs in their code. The only way to prove it really is the library is to have a code sample that does nothing except a few initializations, and calling the API functions that you're claiming cause random crashes.
I have seen too many times where the user claims "it's the library", and when the code the user wrote is finally analyzed, the code is full of bugs that can cause all sorts of havoc (i.e. passing uninitialized pointers to functions, improper handling of dynamically allocated memory, etc.)
Regards,
Paul McKenzie