prefer_correct_error_name

v1.0.0WarningConfigurableClass Naming

Flags a class implementing Exception or extending Error that is not named with the matching suffix.

Dart draws a real line between the two: an Exception is a condition the caller is expected to handle, an Error is a bug the caller should not catch. The name is where that distinction shows up at the catch site.

This rule is in the pedantic preset, and works with its defaults — no configuration needed.

Don’t

class NotFound implements Exception {   // LINT: implements Exception, does not end in `Exception`
  const NotFound(this.id);

  final String id;
}

class BadState extends Error {}         // LINT: extends Error, does not end in `Error`

Do

class NotFoundException implements Exception {
  const NotFoundException(this.id);

  final String id;
}

class BadStateError extends Error {}

Examples

An indirect ancestor still counts

A class that reaches Exception through your own base class is checked the same way:

class ApiException implements Exception {}

// Don't
class RateLimited extends ApiException {}          // LINT

// Do
class RateLimitedException extends ApiException {}

A class that is neither is left alone

The rule only looks at classes that actually reach Exception or Error. A plain result type is never reported, however it is named:

// Not reported — implements neither
class NotFound {
  const NotFound(this.id);

  final String id;
}

Error wins when a class is both

A class can implement Exception and extend Error. The rule asks for the Error suffix, because “do not catch this” is the stricter reading:

// Accepted
class WeirdError extends Error implements Exception {}

Accepting a house vocabulary

Many codebases name their handled conditions Failure rather than Exception. Add it to allow_suffixes and both spellings pass, without giving up the check on classes that end in neither:

analysis_options.yaml

analysis_options.yaml

many_lints:
  rules:
    prefer_correct_error_name:
      allow_suffixes: [Failure]

many_lints.yaml

many_lints.yaml

rules:
  prefer_correct_error_name:
    allow_suffixes: [Failure]

// Both accepted
class NetworkFailure implements Exception {}
class NotFoundException implements Exception {}

// Still reported — ends in neither
class Timeout implements Exception {}   // LINT

Replacing the suffix outright

Set exception_suffix when the house word is the only one you want:

rules:
  prefer_correct_error_name:
    exception_suffix: Failure

// Don't — `Exception` is no longer the accepted ending
class NotFoundException implements Exception {}   // LINT

// Do
class NotFoundFailure implements Exception {}

Enabling this rule

This rule is in the pedantic preset, so it is enabled by preset: pedantic or by name:

many_lints.yaml

rules:
  prefer_correct_error_name:
    enabled: true

Options

Option	Type	Default	Description
exception_suffix	string	Exception	Required ending for an Exception class
error_suffix	string	Error	Required ending for an Error class
allow_suffixes	list	[]	Additional endings accepted alongside the required one, for both kinds

Known limitations

Classes only. A mixin or extension type implementing Exception is not checked.

No quick fix. Renaming a thrown type touches every catch and every on clause that names it, which is a rename refactoring rather than a one-file edit.

Turning this rule off

To disable this rule:

many_lints.yaml

rules:
  prefer_correct_error_name: false

To keep the rule on but skip certain paths, use per-rule exclude.

Related rules

• prefer_correct_callback_field_name — Name callbacks onSomething, the way Flutter does.
• prefer_correct_handler_name — Name event handlers after the event they answer.
• prefer_correct_setter_parameter_name — Use one parameter name in every setter.
• prefer_boolean_prefixes — Name booleans as questions.