try catch

[ProgrammerC++]

Hello

I was wondering this.
Does a try catch, catch a 0xC0000005 error, and the app can continue running after it occured?

thanks

[Lindley]

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.

[Skizmo]

No. Try/catch is not designed for unexpected situations

Say what ? If it is not designed to handle unexpected errors, then what is it supposed to handle ?

try
{
  // this will trigger a crash
   ((CWnd*)12345678)->ShowWindow (SW_SHOW);
}
catch (...)
{
  // do nothing
}

This code shows the user nothing and will continue to execute the rest of the code.

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.

Really, I have to disagree 200% with this statement. Using a try/catch as a pseudo return code is HORRIBLE !

[ProgrammerC++]

I'll try Skizmo's approach and see if it works, i'll reply in a moment

[Paul McKenzie]

Hello

I was wondering this.
Does a try catch, catch a 0xC0000005 error, and the app can continue running after it occured?

In C++, try/catch is only possible if a C++ throw has occurred. The "throw" has to either

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

[Lindley]

Say what ? If it is not designed to handle unexpected errors, then what is it supposed to handle ?

try
{
  // this will trigger a crash
   ((CWnd*)12345678)->ShowWindow (SW_SHOW);
}
catch (...)
{
  // do nothing
}

This code shows the user nothing and will continue to execute the rest of the code.


Really, I have to disagree 200% with this statement. Using a try/catch as a pseudo return code is HORRIBLE !

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.

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.

[ProgrammerC++]

Skizmo's code doesnt do the trick unfortunately

Guess there's no way to continue if a 0xC0000005 occurs :\

[Lindley]

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.

[JVene]

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.

[Lindley]

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++.

[Elrond]

And that anyway, *** lindley pointed out, having such an exception means that the code is not correct...

[JVene]

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:

int z=5;
int r=0;

int d = 0;

try 
 {
  d = z / r;
 }
catch(...)
 {

 }

In the default setting this fires off a 0xC0000094 exception, integer division by zero.

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).

[ProgrammerC++]

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())

[Lindley]

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.

[JVene]

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.