home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!UB.com!igor!thor!rmartin
- From: rmartin@thor.Rational.COM (Bob Martin)
- Newsgroups: comp.lang.c++
- Subject: Re: GOTO, was: Tiny proposal for named loops.
- Message-ID: <rmartin.714862459@thor>
- Date: 26 Aug 92 20:54:19 GMT
- References: <TSOS.61.714395736@uni-duesseldorf.de> <1992Aug21.203635.2917@alias.com> <rmartin.714668024@thor> <2299@devnull.mpd.tandem.com> <rmartin.714749390@thor> <TMB.92Aug25220434@arolla.idiap.ch>
- Sender: news@Rational.COM
- Lines: 32
-
- tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
-
- |After many postings extolling the evils of "break", "return" and other
- |"non-structured" exits from blocks, Bob Martin writes in article
- |<rmartin.714749390@thor>:
-
- | In a real application, when confronted with memory outage, I would
- | throw an exception, call assert, or just plain exit.
-
- |What is an exception exception other than an exit from a block? How is
- |that going to leave your "pre- and postconditions" intact?
-
- Exceptions do not return to the invoking block, they return to another
- block which is declared to catch the exception.
-
- |Altogether, I find Bob's arguments against "break" unconvincing. There
- |is nothing wrong with using "break", exceptions, or even the
- |occasional "goto" in C++, since C++ has mechanisms (destructors) that
- |can be used to take care of cleanup jobs when a block is exited from
- |anywhere; simply use them.
-
- And I disagree, in part. Yes, use exceptions and exits where
- necessary. But avoid break and continue where possible, and avoid
- goto altogether.
-
-
-
- --
- 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++
-