| Scott M. Anderson on 8 May 2003 02:34:01 -0000 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [ALACPP] Daily Dose of O'Reilly Goodness |
Let's continue your example of division by zero. Suppose I'm using a division routine in my Quixotic quest to revamp Johannes Bode's principle relative planetary distances to reinstitute it as a Law of Nature. I divide each planet's distance from the sun by the Earth's distance to get the proper ratios. Now, suppose I've entered the Earth's distance into some kind of field rather than declare it as a constant variable, so I may dicker with decimal places and/or units as I see fit. I never EXPECT it to change.
BUT I certainly hope that my division routine has exception handling so my program doesn't crash JUST IN CASE something unexpected happens to my field, and it ends up set to zero.
Really robust exception handling is designed to handle all POSSIBLE cases, and can only handle what the programmer might EXPECT to see under all the dire circumstances they can conceive of. Thrown exceptions may handle cases that the program never actually EXPECTS to see, however.
Peter Oliphant wrote:
Ok, the discussion begins... :) On the website page discussing exception programming, http://www.oreillynet.com/pub/a/network/2003/05/05/cpluspocketref.html the following is a paragraph quote:"Exception handling is one particularly effective approach to dealing with unexpected, or exceptional, conditions. Without exception handling, dealing with exceptional conditions often requires complicated, multi-way conditionals that are heavily nested and awkward. Exception handling offers a natural way to reduce such intricate and error-prone sections of code."I take - ahem - exception to the first sentence of the paragraph. Exception programming does NOT handle "unexpected" cases. It can't. In fact, exception handling code deals with EXPECTED but UNUSUAL cases (this is suggested in remainder of paragraph). In other words, I don't consider the terms "unexpected" and "unusual" to be the same in this context.Let me illustrate by example. A classic exception is for division by zero. An exception is appropriate here because, in general, division of any number by any other number causes no problems - EXCEPT - for division by zero. Exception code allows the writing of code which IGNORES the division by zero possibility in the general case, and then CATCHES the exceptional case of division by zero. It allows code to be written without a lot of 'paranoia' testing which would have to be done in every call to the code in question (e.g., if the divisor is zero go to alternate (or skip) processing before every single division operation). It therefore saves code space, execution time, and simlifies programmer design by allowing the isolation of code responsible for the odd cases.Ok, this is a bit semantical, but what discussions aren't? ; ) /== P ==\From: "Jon Stewart" <stew1@xxxxxxxxxxx> Reply-To: stew1@xxxxxxxxxxx To: alacpp@xxxxxxxxxxxxxxxxxxxxx Subject: [ALACPP] Daily Dose of O'Reilly Goodness Date: Wed, 07 May 2003 09:43:19 -0700 Exceptions: http://www.oreillynet.com/pub/a/network/2003/05/05/cpluspocketref.html Libraries: http://www.oreillynet.com/pub/a/network/2003/05/06/cplusplusian.html -- Jon Stewart stew1@xxxxxxxxxxx _______________________________________________ alacpp mailing list alacpp@xxxxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/alacpp_________________________________________________________________STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail_______________________________________________ alacpp mailing list alacpp@xxxxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/alacpp
_______________________________________________ alacpp mailing list alacpp@xxxxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/alacpp