oxc-project/oxc · info

Unexpected use of `continue` statement.

Error message

Unexpected use of `continue` statement.

What it means

Diagnostic from the oxlint rule `no-continue` (crates/oxc_linter/src/rules/eslint/no_continue.rs). It is a stylistic restriction rule that fires on every `continue` statement, per the ESLint original: `continue` jumps control flow and some teams ban it to keep loops readable and force restructured conditions.

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_continue.rs:9

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;

use crate::{AstNode, context::LintContext, rule::Rule};

fn no_continue_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Unexpected use of `continue` statement.")
        .with_help("Do not use the `continue` statement.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoContinue;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Disallow `continue` statements.
    ///
    /// ### Why is this bad?
    ///
    /// The continue statement terminates execution of the statements in the current iteration of the current or labeled loop, and continues execution of the loop with the next iteration. When used incorrectly it makes code less testable, less readable and less maintainable. Structured control flow statements such as if should be used instead.
    ///
    /// ### Examples
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

1. Restructure the loop body so the guard becomes an `if` around the work: `if (!skip(i)) { work(i); }`.
2. Filter the iterable before looping: `for (const i of items.filter(notSkipped)) {...}`.
3. If `continue` is the clearest form and the team accepts it, disable the rule in .oxlintrc.json (`"no-continue": "off"`).
4. For isolated cases keep the code and suppress inline with `// oxlint-disable-next-line no-continue`.

Example fix

// before
for (const item of items) {
  if (!item.active) continue;
  process(item);
}

// after
for (const item of items) {
  if (item.active) {
    process(item);
  }
}

When it happens

Trigger: Any ContinueStatement in the scanned source — `for (...) { if (skip(i)) continue; work(i); }` — regardless of loop type or label.

Common situations: Adopting oxlint with the eslint `restriction` category or porting an ESLint config that included `no-continue`; existing loops using guard-clause `continue` patterns suddenly reported; mixed teams arguing over loop style.

Related errors

• Unexpected use of `{operator:?}`.
• Expected a `break` statement before `case`.
• Expected a `break` statement before `default`.
• Label in continue statement is not allowed
• Unnecessary return statement.

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/625a45495ff4b1fc. Report an issue: GitHub.