J
JohnQ
(The thread "Error Handling Idioms" prompted this post. I meant to post it
at the top level, but it got posted as a reply. So here it is again!)
An attempt at common defintions:
fault: the cause of error.
error: a detected fault.
error handling: planned processing (perhaps via formal mechanisms) that
occurs upon fault detection.
error correction: returning a program (or system) back to an error-free
state.
failure: deviation from specified behavior (such as that which occurs when
an fault is not detected or an error not corrected or aborting).
C++ exception mechanisms, function return codes: 2 ways to facilitate
transfer of control to error handling code.
Note that by the above definitions, it is not always obvious if failure has
occurred. Case A: If a stray electron caused a memory bit to toggle and
caused the program to restart but then behave from there on as expected, I'd
say that is not failure. Case B: OTOH, if the program continually restarts,
I'd call that a failure.
Case A
Fault: stray electron. Error: noted memory corruption. Handling: solves
problem. Failure: Yes. Recovery: Yes.
Case B
Fault: dunno. Error: noted memory corruption. Handling: does not solve
problem. Failure: Yes. Recovery: No.
There are more important things (such as understanding of failure modes) to
worry about than which mechanism one uses to transfer control to an error
handler, IMO. C++ exceptions don't help with detection or correction ('try'
is not detection and 'catch' is not correction), the most important parts.
Also, I think that maybe trying to talk about errors in general rather than
specific errors or categories of errors may be futile.
John
at the top level, but it got posted as a reply. So here it is again!)
An attempt at common defintions:
fault: the cause of error.
error: a detected fault.
error handling: planned processing (perhaps via formal mechanisms) that
occurs upon fault detection.
error correction: returning a program (or system) back to an error-free
state.
failure: deviation from specified behavior (such as that which occurs when
an fault is not detected or an error not corrected or aborting).
C++ exception mechanisms, function return codes: 2 ways to facilitate
transfer of control to error handling code.
Note that by the above definitions, it is not always obvious if failure has
occurred. Case A: If a stray electron caused a memory bit to toggle and
caused the program to restart but then behave from there on as expected, I'd
say that is not failure. Case B: OTOH, if the program continually restarts,
I'd call that a failure.
Case A
Fault: stray electron. Error: noted memory corruption. Handling: solves
problem. Failure: Yes. Recovery: Yes.
Case B
Fault: dunno. Error: noted memory corruption. Handling: does not solve
problem. Failure: Yes. Recovery: No.
There are more important things (such as understanding of failure modes) to
worry about than which mechanism one uses to transfer control to an error
handler, IMO. C++ exceptions don't help with detection or correction ('try'
is not detection and 'catch' is not correction), the most important parts.
Also, I think that maybe trying to talk about errors in general rather than
specific errors or categories of errors may be futile.
John