home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12860 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  3.7 KB
  1. Path: sparky!uunet!olivea!hal.com!decwrl!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!UB.com!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: break/continue (was: Re: Tiny proposal for named loops.)
  5. Message-ID: <rmartin.714756719@thor>
  6. Date: 25 Aug 92 15:31:59 GMT
  7. References: <rmartin.714435942@dirac> <rw.714437749@frito> <rmartin.714669410@thor> <1992Aug25.034553.575@frumious.uucp>
  8. Sender: news@Rational.COM
  9. Lines: 80
  10.  
  11. pat@frumious.uucp (Patrick Smith) writes:
  12.  
  13.  
  14. |   In several articles, rmartin@thor.Rational.COM (Bob Martin)
  15. |   explains why he believes continue and break (out of a loop)
  16. |   statements should not be used.
  17.  
  18. |I think the merits of break and continue (or the harm done by them)
  19. |depend on the assumptions made by the person reading the code.
  20. |Ideally, the author and the reader share the same assumptions,
  21. |but that's not often true.
  22.  
  23. [ ... nice explanation deleted ... ]
  24.  
  25. |Many of us must read code written by other people, so don't have
  26. |the luxury of assuming there will be no continue statements, no
  27. |breaks out of loops, no returns from the middle of functions, etc.
  28. |So the extra value of coding without these things is much lower
  29. |than it would be if we could make these assumptions.
  30.  
  31. This is unfortunately true.  However, I don't view this as a license
  32. to use breaks and continues.  That would be equivalent to saying "Why
  33. should I clean the dishes, they'll just get dirty again."
  34.  
  35. |However, there is one type of unstructured code that pervades most
  36. |of the code I write, and which I would be most reluctant to give up.
  37. |This is error checking code similar to
  38.  
  39. |   if (condition) error("Oops!");
  40.  
  41. As you please.  I have not problem with calls to error, but I prefer
  42. this model:
  43.  
  44.     if (condition)
  45.         do some good work.
  46.     else
  47.         error.
  48.  
  49. This maintains structure as well as taking advantage of error.
  50.  
  51. |where error() is a function which will terminate the program (probably
  52. |after printing the indicated message).  Sometimes half the code in
  53. |a function will consist of such error checking; changing the function
  54. |to have only one exit point can make its logic much more convoluted.
  55. |And then every place where the function is called, you would have
  56. |to insert a check as to whether the function succeeded!
  57.  
  58. No, the logic is nearly identical.  But in one case you are pretending
  59. that it is not nested, and in the other you are expressing the
  60. nesting. 
  61.  
  62. As for checking the function call for error, if you don't want to do
  63. that, then call error within the function.  
  64.  
  65. |Similar error checking code using exceptions will be even less
  66. |structured, since throwing an exception will be essentially a
  67. |different type of return from a function, instead of a consistent
  68. |"stop this program _now_!" command.  But that doesn't bother me
  69. |in the slightest; I'll be very happy when I'm able to use exceptions,
  70. |as I think they will make proper error-handling much less
  71. |cumbersome.
  72.  
  73. No, exceptions do not violate structure (IMHO).  The function which
  74. throws an exception never returns!  The calling code preserves its
  75. invariants.  The exception is caught by code which expects it, so its
  76. invariants are not violated either.
  77.  
  78. Nor do exceptions violate single entry single exit, since the
  79. exception is not an exit, it does not return to the caller.  Rather it
  80. is caught by a higher level catch which is itself written in a
  81. structured block.
  82.  
  83. So, I have no problem with exceptions, or with calls to error.
  84.  
  85.  
  86. --
  87. Robert Martin                        Training courses offered in:
  88. R. C. M. Consulting                       Object Oriented Analysis
  89. 2080 Cranbrook Rd.                        Object Oriented Design
  90. Green Oaks, Il 60048 (708) 918-1004       C++
  91.