Skip to content

unicorn/catch-error-name Style

🚧 An auto-fix is still under development.

What it does

This rule enforces consistent and descriptive naming for error variables in catch statements, preventing the use of vague names like badName or _ when the error is used.

Why is this bad?

Using non-descriptive names like badName or _ makes the code harder to read and understand, especially when debugging. It's important to use clear, consistent names to represent errors.

Examples

Examples of incorrect code for this rule:

javascript
try {
} catch (badName) {}

// `_` is not allowed if it's used
try {
} catch (_) {
  console.log(_);
}

promise.catch((badName) => {});

promise.then(undefined, (badName) => {});

Examples of correct code for this rule:

javascript
try {
} catch (error) {}

// `_` is allowed if it's not used
try {
} catch (_) {
  console.log(123);
}

promise.catch((error) => {});

promise.then(undefined, (error) => {});

Options

name

{ type: string, default: "error" }

The name to use for error variables in catch blocks. You can customize it to something other than 'error' (e.g., 'exception').

Example:

json
"unicorn/catch-error-name": [
  "error",
  { "name": "exception" }
]

ignore

{ type: Array<string | RegExp>, default: [] }

A list of patterns to ignore when checking catch variable names. The pattern can be a string or regular expression.

Example:

json
"unicorn/catch-error-name": [
  "error",
  {
    "ignore": [
      "^error\\d*$"
    ]
  }
]

How to use

To enable this rule in the CLI or using the config file, you can use:

bash
oxlint --deny unicorn/catch-error-name
json
{
  "rules": {
    "unicorn/catch-error-name": "error"
  }
}

References

Released under the MIT License.