I may have been exposed to exactly the wrong languages, but though many have loops and break statements, none of the languages I am familiar with have higher-order break statements¹. While a regular break statement terminates the innermost loop inside which it is executed, such a break(n) statement would terminate the n innermost loops.

For example using such a statement, I could write in Python:

for i in range(100):
    for j in range(100):
        if foo(i,j):

As Python lacks such a statement, however, I have to do something like the following:

broken = False
for i in range(100):
    for j in range(100):
        if foo(i,j):
            broken = True
    if broken:

(I am aware that there are other ways to do this, such as raising exceptions. This serves just as an example.)

In another example, this is one of the prominent reasons to use a goto statement in C/C++. While goto allows for a close equivalent of a higher-order break, it introduces a new syntactical element (unless one already uses gotos). Not to forget that goto is frowned upon by many – be it justified or not.

While I see that using a higher-order break statement is not something most people use on a daily basis, this also applies to a lot of other language features. Also, a higher-order break statement does not seem difficult to implement to me and would be rather intuitive to use.

Is there a good reason why programming languages would have a break statement but not a higher-order break statement? I am thinking of things like inherent conceptual problems, broken paradigms or error vulnerability.

¹ Though, when researching for this question, I learnt that PHP has them.

  • 1
    Perl and Java both have this.
    – nobody
    Commented Sep 15, 2014 at 16:28
  • 9
    Most languages have labelled break statements, which are more explicit and in my opinion much preferable. Commented Sep 15, 2014 at 16:28
  • 4
    Because having boatloads of nested blocks and using break in the first place are both ill-advised? (The latter more debatably) Languages have enough challenges without solving problems that people shouldn't be doing anyways.
    – Telastyn
    Commented Sep 15, 2014 at 16:33
  • 1
    Some languages have goto, others have call/cc, or throw (and C has longjmp) .... Commented Sep 15, 2014 at 16:55
  • 4
    "higher ordered" is not a good term for this... it has another meaning in computer science
    – JoelFan
    Commented Sep 15, 2014 at 17:54

2 Answers 2


Is there a good reason why so few programming languages have higher-order break statements?

Using SO tags as the metric, the seven most popular programming languages in use today are Java, C#, Javascript, PHP, Python, C++, and Objective C. Of these languages,

  • Java and Javascript have labeled break

  • C++, C#, and Objective C have goto, which is a more general control statement that solves the same problem. They also all have break, naturally, but no multi-level or labeled break

  • PHP has both nested (multi-level) break and goto

  • and Python is the odd man out with no goto and no labeled break.

So maybe a better question is,

Why doesn't Python have goto or labeled break? ;)

This question has an answer to that question:

Guido rejected it because "code so complicated to require this feature is very rare". The PEP does mention some workarounds, though (such as the exception technique), while Guido feels refactoring to use return will be simpler in most cases.

Personally, I think Python should have one or both, but that is opinionated so don't take it as part of this answer.

  • C# also has break and continue. goto is very rarely used, usually to patch multiple case statements together. Commented Sep 15, 2014 at 18:17
  • One of the answers of interest to the question cited about Python's reasoning: PEP 3136 proposes labeled break/continue. Guido rejected it because "code so complicated to require this feature is very rare". The PEP does mention some workarounds, though (such as the exception technique), while Guido feels refactoring to use return will be simpler in most cases. stackoverflow.com/a/190070/279112 Commented Sep 15, 2014 at 18:19
  • That being said, I would never use a try...catch to do something like that, as has been cited in the question on this thread and seemingly that answer. Exceptions/errors should only be used for exceptions and errors. Commented Sep 15, 2014 at 18:21
  • Thx @Panzercrisis, I have edited to quote the interesting part you spotted.
    – x-code
    Commented Sep 15, 2014 at 18:27
  • @Panzercrisis Exceptions are cheap and idiomatic in Python, and "exceptions and errors" is subjective. To you a file being missing may be an error; to me that's expected behavior (because you can't make any assumptions about the state of the world outside your process).
    – Doval
    Commented Sep 15, 2014 at 18:34

Because while and until provide clearer semantics. They provide higher level abstractions for expressing programmer intent. The semantics of break are imperative at the lower level of instructions to the computer. They are closer to that of machine code - like goto, break is thin syntactic sugar over JMP.

McConnell's basic advice:

When to Use a for Loop. If you have a condition under which execution has to jump out of a loop, use a while loop instead....Most complicated looping tasks are better handled by a while loop. -- Code Complete [first edition] pp 329.

This is really just an extension of his more general advice:

Use break and continue only with caution. Use of break eliminates the possibility of treating a loop as a black box. Limiting yourself to only one statement to control a loop's exit condition is a powerful way to simplify your loops. Using break forces the person reading your code to look inside the loop for an understanding of the loop control. This makes the loop more difficult to understand. -- Code Complete [first edition] pp 337-338.

In the end his "key point" is:

Minimize the number of factors that affect the loop. Simplify! Simplify! Simplify! Second treat the inside of the loop as if it were a routine -- keep as much of the control as possible outside the loop. Explicitly state the conditions under which the body of the loop is to be executed. Don't make the reader look inside the loop to understand the loop control. Think of a loop as a black box: The surrounding program knows the control conditions but not the contents.

  • 12
    It's a shame that, after all this time, some folks still think that deeply nested if/else statements are somehow clearer than a well-placed break or continue, or that a single point of exit is still preferable to a guard clause. Commented Sep 15, 2014 at 16:36
  • 1
    Python unlike many other languages, loves the idea of "one true way". In the rest of the world, things are not always so hard and fast. Even Code Complete admits as much. But it still recommends while and until as the best first approach. Then cond\case\switch. And only then, treating something as a corner case. Deeply nested if..then..else does not get much love. Socartes and 孔夫子 beat you to complaining about youth by 2.5 millennia. YMMV. Commented Sep 15, 2014 at 16:40
  • 1
    When I use break and continue, they express my intent just fine thankyouverymuch.
    – user7043
    Commented Sep 15, 2014 at 17:24
  • 2
    Could you please back up the opinions expressed in this answer with objective facts or reliable sources? As it stands, another user could simply post a contradicting answer like “Using break clearly expresses programmer intent and is on a much higher level than goto. Setting boolean flags to break out of nested loops is far less clear than using a labeled break”.
    – amon
    Commented Sep 15, 2014 at 18:05
  • 1
    "Syntactic sugar" is always used to downgrade some aspect of a language with no good reason. Why doesn't anyone complain that 'if' is syntactic sugar over a conditional JMP (shudder...) and 'while' is just syntactic sugar over a conditional JMP with another JMP going backwards (yikes)?
    – Florian F
    Commented Sep 15, 2014 at 21:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.