break, continue & Labeled Control Flow

break and continue adjust loop and select flow, while labels let you target an outer for, switch, or select when nested logic would otherwise need flags or duplicated conditions.

Used sparingly, labels clarify intent; overused, they obscure structure.

Summary

break exits the innermost for, switch, or select.

continue skips to the next iteration of the innermost loop.

A label on a loop or select lets break label or continue label target that statement.

break inside select only exits the select, not the surrounding loop, unless labeled.

Refactoring into a helper function is often clearer than deep labels.

Recipe

Quick-reference recipe card - copy-paste ready.

package main
 
import "fmt"
 
func main() {
    for i := 0; i < 5; i++ {
        if i == 2 {
            continue // skip printing 2
        }
        if i == 4 {
            break // stop before 4
        }
        fmt.Println(i)
    }
}

When to reach for this:

• Use continue to skip irrelevant iterations without nesting another if body.
• Use break when further iterations cannot change the outcome (found target, error).
• Use labeled break to leave a search in nested loops without found booleans.
• Extract a function when more than one label or multiple exits make the flow hard to scan.

Working Example

package main
 
import (
    "fmt"
    "time"
)
 
func findPair(matrix [][]int, target int) (int, int, bool) {
search:
    for r, row := range matrix {
        for c, v := range row {
            if v == target {
                return r, c, true
            }
            if v < 0 {
                break search // abort entire search on sentinel
            }
        }
    }
    return 0, 0, false
}
 
func poll(ctxDone <-chan struct{}) {
    ticker := time.NewTicker(100 * time.Millisecond)
    defer ticker.Stop()
 
loop:
    for {
        select {
        case <-ctxDone:
            break loop // leave the for, not just select
        case <-ticker.C:
            fmt.Println("tick")
        }
    }
    fmt.Println("stopped")
}
 
func main() {
    m := [][]int{{1, 2}, {-1, 9}, {3, 4}}
    r, c, ok := findPair(m, 9)
    fmt.Println("found", r, c, ok)
 
    done := make(chan struct{})
    go func() {
        time.Sleep(250 * time.Millisecond)
        close(done)
    }()
    poll(done)
}

What this demonstrates:

• Labeled break search exits nested loops on a sentinel value.
• Returning (r, c, true) is an alternative to labeled break when results are needed.
• break loop on a select inside for exits the outer loop, not just the select.
• continue is not shown here but would skip to the next ticker iteration similarly.

Deep Dive

How It Works

• break and continue apply to the innermost active construct of their kind.
• Labels must be attached to a for, switch, or select statement - not arbitrary blocks.
• goto exists in Go but is discouraged except in rare code generators and low-level optimizations.
• return exits the entire function, which often replaces labeled breaks in helpers.
• select with default plus break can busy-loop if you forget to block or sleep.

break vs continue vs return

select + for Pattern

for {
    select {
    case <-ctx.Done():
        break loop   // exits for, not only select
    case v := <-ch:
        handle(v)
    }
}

Without the label, break would only exit select and immediately re-enter the for.

Go Notes

// Prefer early return over labeled break when computing a result
func contains(haystack []string, needle string) bool {
    for _, s := range haystack {
        if s == needle {
            return true
        }
    }
    return false
}

Gotchas

• break only exits select - for { select { case <-done: break } } loops forever. Fix: use break loop with a label on the for, or return.
• Labeled continue on switch - continue targets loops only, not switch. Fix: restructure or use return.
• Flag variables instead of labels - found booleans with multiple break levels confuse readers. Fix: label once or extract a function.
• continue skips delay logic - Placing continue before rate limiting causes tight loops. Fix: put throttling after the continue check or at loop end.
• Breaking from defer - break does not cross function boundaries. Fix: use return from the helper.
• goto as a substitute - Unlabeled jumps harm readability. Fix: prefer structured control flow and functions.

Alternatives

FAQs

Related

• for Loop Variants & range Semantics - loops you break out of
• Control Flow Basics - introductory break/continue
• Go Control Flow: Expression-Oriented Design - flat flow guidance
• range Variable Reuse Pitfalls - closures inside loops you may continue past
• Control Flow Best Practices - refactor nested logic

Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).

NzA2MjAyfDg5M29pZ2N8b2kuc2VkaXVnZWRvYw==