Re: Assertion vs Exception Handling
On 15 Mar., 15:54, "Daniel T." <danie...@earthlink.net> wrote:
Ian Collins <ian-n...@hotmail.com> wrote:
On 03/15/10 03:03 PM, Daniel T. wrote:
I define [an error] as something the program cannot recover from.
When the design says, "If the user does X, then the program must to
Y," I don't call it an error when the user does X. If the design
requires that condition A must pertain at point B, and condition A
does not pertain at point B; I call *that* an error.
Exceptions are for exceptional circumstances. If something that
shouldn't fail fails, that's and exceptional circumstance. That's wh=
y
I mentioned file opening failing, if the file should be there, throw
if it isn't. If it's expected to sometimes not be there, deal with i=
t
on the spot.
The above is essentially what I have been saying all along. How are our
positions different again?
In your belief that an exception should always lead to the termination
of the program and that detetion of a a programming error should lead
to an exeption. This is absolutely silly.
If something is guaranteed not to happen, assert if it does!
I would add that you only should use the assert macro if you know for a
fact that every program that might ever use the function in question
will find aborting without cleanup an acceptable alternative.
And what kind of program would not want to abort without cleaning up?
In general you would want to do as little as possible after a program
violation has been detected. About the only reasonable thing to do is
asking the backup program to take over, but that should happen
automatically anyway.
The one exeption to this I can think of is game-programming.
/Peter