I'm sorry, I didn't read much of your treatise
below the point where I cut it off, but it was
quite bad enough by then that I didn't care to
see where you went from that.
There's another old principle of not continuing
on when you know you're likely to blow up. Sure,
if you don't know how to handle ErrBodilyInjuryDueToLawnMower
you shouldn't be expected to call 911 ... but you
should certainly know enough to STOP RUNNING THE
LAWNMOWER! (Doctor, it hurts when I do this; Well,
stop doing that!)
If you don't know how to handle it properly, there
certainly isn't much benefit in doing random fixups,
but there is just as certainly no benefit on continuing
on as if the error had not occurred.
If you get an error you don't know how to handle,
the best thing to do is STOP. Notify the user.
Do not pass "GO", do not collect 200 more errors.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: Kenneth Albanowski [mailto:[EMAIL PROTECTED]]
>
> Er, well, sort-of. There's this old principle of not handling
> errors if
> you don't know what to do about them. I.e., if MemHandleNew turns
> ErrBodilyInjuryDueToLawnMower, the OS shouldn't require your
> program to
> set up the modem to call 911.
...
> Logically it is necessary to check the error result of every
> function that
> can return an error, but if there is nothing you can actually
> do about any
> of them, there may not actually be any benefit.
