Re: Tasty exceptions

Craig Stuntz [TeamB] wrote:
Michael C. wrote:


I reread it.
I think you missed my point too. ;-)


No, you're still only talking about issues you've explicitly planned
on, and code you have written. You're still talking about isolated
examples of particular cases where error codes work OK, and not
considering a strategy which works generally with code written by
others.

For an example of how eating exceptions (even inadvertantly) can hurt
you in the real world, consider this:

http://blogs.teamb.com/craigstuntz/archive/2004/08/24/ATrickQuestionAndA
nImportantLesson.aspx


Sure, you could use that as an example why one should not eat exceptions.
But I'm afraid it's probably not a typical scenario.

Let me point out the opposite perspective:
NOT eating exception can hurt you in the real world too.
Suppose an exception was raise ( for example, you tried to free a nil pointer or something TRIVIAL you DIDN'T expect ) in the middle of processing 1000 bitmaps,
your path of execution was stop, a dialog box was raise, and your program stopped processing the images.
I don't think the user of your software would be sympathetic to that error handling strategy.


Ask yourself: Does every function you have ever written return an
error code, and does every function explicitly check all of the
possible errors from everything it calls? If so, you *might* be safe.
Maybe.

We are never safe from errors.
It's how you respond to them which is important (to the user).


.