Re: Divide by 0 - exception thrown?
"Jason Doucette" <www.jasondoucette.com> wrote in message
news:uEntUfj8GHA.1256@TK2MSFTNGP04.phx.gbl...
It is generally considered a defect in C++ compilers before VS2005 that a
catch-all catch clause
catch ( .... )
{
}
Um, did I miss something?
Only the fact that I am too easily distracted. (There are days like today
when I have OE open all day - sometimes I walk away from my desk in mid post
and forget where I was when I left. It is an age thing. <g>)
I don't believe you finished your sentence.
You are right.
Were you about to say that it sometimes catches SEH?
That's right. With VS2005 it should NOT do that unless you tell it to by
compiling with the /EHa option.
I feel I should say this, although off-topic: I've found that using catch
(...) is almost always a no-no. If you merely catch every exception,
sometimes you'll catch ones that are *really* bad, and you can do nothing
to save your application from crashing (maybe you can right then, but not
2 ms later). The issue is so severe, that your program will crash anyway.
This means the effort is futile.
There is a enough to be said on the topic of exceptions for a book (or
twelve) by language experts of which I am not one.
On a personal level - and please don't try this at home <G> - in much of
what I write in C++ I tend to use return codes a lot and exceptions only
sparingly. On the .Net platform or with Java, exceptions feel more natural.
(That may have nothing to do with anything except the fact that I grew up on
assembly language, Fortran, Pascal and C where exceptions were not
available).
Now, if you let these exceptions go (i.e. don't catch them), at least the
OS will report an error with crash information that you can use to locate
the source problem, if you have a MAP file:
http://www.codeproject.com/debug/mapfile.asp
(And, if you have made a deal with Microsoft, you can collect a database
of these "crash information"s to analyze from the field. Very useful.
Or, you could roll your own solution with a bug reporting system + local
bug tracking software.)
Exactly right. If the application is not too badly hosed you can try to
create a mini-dump
http://windowssdk.msdn.microsoft.com/en-us/library/ms680369(VS.80).aspx
for post mortem analysis. There are good mini-dump samples here, too.
http://www.debuginfo.com/examples/effmdmpexamples.html
On the other hand, if you catch these exception, and attempt to 'save' the
application from crashing, it will likely just crash anyway, and then
you're left with no information. You'll have no idea where the error
occurred...
That is the prevailing wisdom.
Regards,
Will