Re: Exceptions, Go to Hell!
RB
Wouldn't it be prudent to have exception frames to at least cover a
crash report so it could be rectified down the road ?
Goran Pusic"
I am not sure what you mean by "exception frames", not unless if you
think about details of implementation of exceptions for some platform
(which you seem to have done here before), but I guess you mean
something like "let's have an exception if code hits a bug".
But if e.g. code stumbles on a NULL pointer where there should be
none, it could throw e.g. a runtime_error with no harm. ....< cut >
... could work, provided that it's checked in every place it could have
any influence on correct operation. ........< > .........
So... I agree that testing will never catch all bugs, but attempting
to catch them at runtime IMO does not help..................< >
And as you might remember, to me, a crash != exception,
not in C++ sense.
Oh well, sorry for ambuity, I don't necessarily mean use exceptions for error
checking (persay, though sometimes that statement in some areas to me seems
to denote splitting hairs). But (in addition to previous said issues that occur
outside the realm of a bug) I was referring to (as you replied ) where the math
ceilings, floors or zero values were not covered like they should have been.
Say it's in a value realm that does not normally traverse and is somehow not
caught during testing.
Or an illegal address ptr access turns up. Now granted this is a error on the part
of a programmer (am I wrong ? ) since I have coded my own dummy self many
times to protect against ptr address areas (that change address during runtime)
from coming up illegal or even outside the stack. But I would think one would want
to have all the information they can reported back so as to solve their foo bar before
they become unemployed ? Even if you had a near omnipotent handler code in place
to allow for continued execution by resetting the context of the voilating address,
I would think you would still want to know about it.
Specifically some sort of base paradigm (third party) or maybe some simple
thing in like,
// in header file
// ( below type in winbase.h )
static LPTOP_LEVEL_EXCEPTION_FILTER m_prevFilter;
// in cpp file
CMissedSomething :: CMissedSomething( ) // Constructor
{ // Install SEH unhandled exception filter function
m_prevFilter = SetUnhandledExceptionFilter(MyUnCaughtFilter);
.............
// Check some stuff
..........
// send the context and whatever else needed to file and or email and
// hope to God our robotic heart surgery software hasn't killed someone
// before we get this dump.
}
Covering ( reporting an uncaught SEH exception ) the entire app. Obviously this
base setup could not handle inner exception area correction or object destruction
and heap deletetions (without adding inner C++ E frames in said areas ). And
admittedly even this could not catch all errors (that did not cause an SEH exception)
but to me this seems like a step in the right direction. But even say the omnipotent
handler could also call the into a report class (separate from MyUnCaughtFilter) and
still issue a report even if execution continues by resetting the illegal access context to
a legal address ( if said legal reset doesn't cause bad data down the road ).
Again "all" exceptions whether Hardware (divide / 0, etc) or software (RaiseException)
are implemented through the same base understructure. The C++ compiler uses this
same understructure while extending it's capability, albeit it does not attempt to cover
ascyncronous (SEH ) tracking. But once you get past the unwinding and object
destruction differences it all comes down to a raised exception.
Anyhow just my view looking out from my learning portal and listening to the pros.
No need to reply if I am too ambiguous but thanks for the thread because it has helped
me conceptualize what I have been studing for awhile.
Oh and by the way I bought the Exceptional C++ you mentioned. I went to Amazon
and got it used for $14 bucks. Can't beat that.
My compiler won't acknowledge exception specifications so I could not disassemble
it to see what it was doing. But after reading the online text of Sutter I was able to see
that when an exception specification says it won't throw anything, it is actually lying.
Rather the truth is the compiler (if it acknowledges said spec) puts in the catch blocks
for you and many times you actually end up with more try catches than if you had typed
them yourself while deciphering where you needed them. Most compilers have
disregarded this specification.