From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: break/continue (was: Re: Tiny proposal for named loops.)
Date: 25 Aug 92 15:31:59 GMT

pat@frumious.uucp (Patrick Smith) writes:


|   In several articles, rmartin@thor.Rational.COM (Bob Martin)
|   explains why he believes continue and break (out of a loop)
|   statements should not be used.

|I think the merits of break and continue (or the harm done by them)
|depend on the assumptions made by the person reading the code.
|Ideally, the author and the reader share the same assumptions,
|but that's not often true.

[ ... nice explanation deleted ... ]

|Many of us must read code written by other people, so don't have
|the luxury of assuming there will be no continue statements, no
|breaks out of loops, no returns from the middle of functions, etc.
|So the extra value of coding without these things is much lower
|than it would be if we could make these assumptions.

This is unfortunately true.  However, I don't view this as a license
to use breaks and continues.  That would be equivalent to saying "Why
should I clean the dishes, they'll just get dirty again."

|However, there is one type of unstructured code that pervades most
|of the code I write, and which I would be most reluctant to give up.
|This is error checking code similar to

|   if (condition) error("Oops!");

As you please.  I have not problem with calls to error, but I prefer
this model:

    if (condition)
        do some good work.
    else
        error.

This maintains structure as well as taking advantage of error.

|where error() is a function which will terminate the program (probably
|after printing the indicated message).  Sometimes half the code in
|a function will consist of such error checking; changing the function
|to have only one exit point can make its logic much more convoluted.
|And then every place where the function is called, you would have
|to insert a check as to whether the function succeeded!

No, the logic is nearly identical.  But in one case you are pretending
that it is not nested, and in the other you are expressing the
nesting. 

As for checking the function call for error, if you don't want to do
that, then call error within the function.  

|Similar error checking code using exceptions will be even less
|structured, since throwing an exception will be essentially a
|different type of return from a function, instead of a consistent
|"stop this program _now_!" command.  But that doesn't bother me
|in the slightest; I'll be very happy when I'm able to use exceptions,
|as I think they will make proper error-handling much less
|cumbersome.

No, exceptions do not violate structure (IMHO).  The function which
throws an exception never returns!  The calling code preserves its
invariants.  The exception is caught by code which expects it, so its
invariants are not violated either.

Nor do exceptions violate single entry single exit, since the
exception is not an exit, it does not return to the caller.  Rather it
is caught by a higher level catch which is itself written in a
structured block.

So, I have no problem with exceptions, or with calls to error.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++