When I teach this stuff, I try to distinguish between (1) Returning/Exiting/Excepting because of a legitimate error condition (2) Returning/Breaking early beca

When I teach this stuff, I try to distinguish between (1) Returning/Exiting/Excepting because of a legitimate error condition (2) Returning/Breaking early because there's either no work to do or something necessary to do the work is absent/unavailable (the latter often turns into a case of (1) (3) Returning/Breaking/Continuing early because I've discovered the work is done for either all iterations or this particular iteration, and the remainder of the function/method/loop is pointless cycling. (Often added during optimization, sometimes added too early). (4) Returning/breaking/GOTOing because I've gotten confused and want to go to a place in the code that makes more sense to me. This is the only that's actually a problem and should be railed against. Unfortunately, it's way more common than it really should be in beginners' programs. I think GOTO got an early bad rap---try writing non-trivial machine code or assembler without liberal use of goto, and many very useful techniques in debugging are basically informed application of goto---because of what I call the "pull the ejection handle" approach to getting into trouble trying to code an algorithm you dont really understand.