This rule raises an issue when error parameters in try/catch blocks, promise.catch() handlers, or promise.then() rejection handlers don’t follow the configured naming convention (defaults to error).

Why is this an issue?

Consistent naming of error parameters improves code readability and maintainability across your codebase. When developers use different names for error parameters (err, e, exception, badName), it creates unnecessary cognitive overhead when reading and maintaining code.

Consistent naming helps developers:

• Quickly identify error handling code
• Understand the purpose of parameters at a glance
• Navigate codebases more efficiently
• Reduce mental context switching between different naming styles

This rule applies to three common JavaScript error handling patterns:

• Traditional try/catch blocks
• Promise .catch() methods
• Promise .then() rejection handlers (second parameter)

The rule is flexible and allows descriptive names like fsError or authError when they provide meaningful context about the type of error being handled.

What is the potential impact?

While this is primarily a code style issue, inconsistent error parameter naming can slow down development and code reviews. It may also make debugging more difficult when developers need to quickly scan through error handling code.

How to fix?

Use the configured parameter name (defaults to error) for catch clause parameters.

Non-compliant code example

try {
  riskyOperation();
} catch (badName) { // Noncompliant
  console.log(badName.message);
}

Compliant code example

try {
  riskyOperation();
} catch (error) {
  console.log(error.message);
}

Documentation

• eslint-plugin-unicorn - Rule catch-error-name
• MDN - try…​catch - Documentation for JavaScript try…​catch statements
• MDN - Promise.prototype.catch() - Documentation for Promise catch method
• ESLint - Configuring Rules - Guide on how to configure ESLint rules