oxc-project/oxc · warning · OxcDiagnostic

The catch parameter {caught_ident:?} should be named {expect

Error message

The catch parameter {caught_ident:?} should be named {expected_name:?}

What it means

Diagnostic from oxlint's `unicorn/catch-error-name` rule. It enforces one consistent, descriptive name for caught errors (default `error`) across `try/catch` bindings, `promise.catch(...)` callbacks, and `promise.then(undefined, ...)` rejection handlers. The message uses Rust debug formatting, so the names render quoted: `The catch parameter "err" should be named "error"`. A binding named `_` is tolerated when it is never referenced, and names whose lowercase form ends with the configured name are accepted.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/catch_error_name.rs:27

use oxc_span::Span;
use oxc_str::CompactStr;
use oxc_syntax::identifier::is_identifier_name;
use schemars::JsonSchema;
use serde::Deserialize;

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

fn catch_error_name_diagnostic(
    caught_ident: &str,
    expected_name: &str,
    span: Span,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!(
        "The catch parameter {caught_ident:?} should be named {expected_name:?}"
    ))
    .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct CatchErrorName(Box<CatchErrorNameConfig>);

#[derive(Debug, Clone, Deserialize, JsonSchema)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct CatchErrorNameConfig {
    /// A list of patterns to ignore when checking `catch` variable names. The pattern
    /// can be a string or regular expression.
    #[serde(default, deserialize_with = "deserialize_regex_vec")]
    ignore: Vec<Regex>,
    /// The name to use for error variables in `catch` blocks. You can customize it
    /// to something other than `'error'` (e.g., `'exception'`).
    #[serde(default = "default_error_name", deserialize_with = "deserialize_error_name")]

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Rename the parameter to `error` — `oxlint --fix` applies it automatically.
  2. Standardize on a different name by setting the rule's `name` option (e.g. "exception") in .oxlintrc.json.
  3. Whitelist legacy names with the `ignore` option (strings or regexes), e.g. ["^e$", "^err$"].
  4. If the error object is unused, switch to the optional catch binding `catch {}` or keep `_` unreferenced.

Example fix

// before
try {
  save();
} catch (err) {
  console.error(err);
}
// after
try {
  save();
} catch (error) {
  console.error(error);
}
Defensive patterns

Strategy: validation

Validate before calling

// .oxlintrc.json — align the rule with your convention before enabling the unicorn preset
{
  "rules": {
    "unicorn/catch-error-name": ["warn", { "name": "error", "ignore": ["^e$", "^err$"] }]
  }
}

Prevention

When it happens

Trigger: Any used catch or rejection-callback parameter whose name differs from the configured `name` (default `error`) and does not match an `ignore` pattern — e.g. `try { ... } catch (err) { console.log(err) }` or `promise.catch(e => ...)`. Also fires when the name is not even an identifier-shaped string after the rule's normalization.

Common situations: Codebases that historically use `e`, `err`, or `ex`; enabling the `unicorn` preset for the first time; refactors that renamed error parameters inconsistently; teams standardizing on `exception` via the `name` option.

Related errors


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