|
|
Back to UserFriendly Strip Comments Index
|
errors | by perldude | 2006-11-19 12:55:59 |
|
That last statement... | by HadEnuf | 2002-06-11 13:34:49 |
|
Said what I meant, meant what I said | by perldude | 2002-06-11 16:58:29 |
| To put it more simply... |
by Schol-R-LEA;2 |
2002-06-11 21:54:43 |
If I understand what you are saying, it seems to me that your really talking about the difference between exceptions (i.e., known possible failure modes or anticipated unusual occurences), and programming errors (mistakes made by the developer). If so, your previous posts could be rewritten as:
Errors are not exceptions, and shouldn't be treated as such - coding around an error or trapping it is still a programming mistake;
It is better for an error to be fatal (cause the program to halt) rather than continue running in an unstable manner;
Most 'exceptions' come programming errors, not failure conditions; and
Failing to anticipate failure modes is a programming error; the programmer should have known every possible failure mode in advance.
I think that the last one is the most troublesome, since in real-world programing, coders often have to work with incomplete or inaccurate information. Defensive programming means you still should handle those cases as gracefully as possible, even if that only means shut down properly and restart rather than panic and core dump. At the very least, such a fatal bug should report that the program and/or hardware slipped into a seemingly impossible state, so the programmers have something to work with when they go to fix it. The same applies to fatal errors, when possible, though of course a wild pointer or memory screw that causes a program to run away can't do much in the way of error reporting. |
|
[ Reply ] |
|
|
[Todays Cartoon Discussion]
[News Index]
|
|
