avoid_get_or_else_swallowing_failure

v1.0.0WarningConfigurablefpdart

This rule flags getOrElse on an Either, TaskEither or IOEither whose callback ignores the failure it is given.

Why use this rule

Either.getOrElse hands its callback the Left value. A callback that ignores that parameter throws the failure away: the pipeline carried the reason all the way to the boundary, and the boundary drops it in favour of a default the caller cannot distinguish from a real result.

Sometimes that is exactly right — a cached value, a display fallback, a genuinely optional lookup. But it is a decision, and written as (_) => 0 it does not look like one. Using the parameter, or folding with match, makes the choice visible to the next reader.

Option.getOrElse takes no parameter and is never reported: there is no failure there to discard.

See also: fpdart: Either

Don’t

int retryCount(Either<String, int> result) => result.getOrElse((_) => 0);

// Naming the parameter and then not reading it is the same discard.
int otherCount(Either<String, int> result) =>
    result.getOrElse((failure) => 0);

Do

Use what you were given:

int retryCount(Either<String, int> result) =>
    result.getOrElse((failure) => failure.length);

Or fold explicitly, so the discard is on the page:

int retryCount(Either<String, int> result) => result.match((failure) {
  print('load failed: $failure');
  return 0;
}, (value) => value);

Known limitations

A named parameter that is never read is reported the same as _, since naming it and then ignoring it is the same discard.

Files under test/ are skipped by default — discarding a failure in a fixture is ordinary. Set ignore_tests: false to report them too.

No quick fix is offered: what to do with the failure is the decision the rule is asking for.

many_lints:
  rules:
    avoid_get_or_else_swallowing_failure:
      ignore_tests: false

rules:
  avoid_get_or_else_swallowing_failure:
    ignore_tests: false

Option	Type	Default	Description
`ignore_tests`	bool	`true`	Skip files under `test/`, where discarding a failure in a fixture is ordinary

Configuration

This rule is in the pedantic preset — it is deliberately opinionated, since a fallback that ignores the failure is often the right call. Turn it on explicitly:

rules:
  avoid_get_or_else_swallowing_failure: true

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

avoid_chain_first_swallowing_failure — chainFirst turns a failing effect into success.
avoid_throw_in_fp_callback — A throw inside an fpdart callback escapes the error channel the pipeline is built to carry.
prefer_and_then — andThen says that the previous value is not used.
prefer_chain_either — chainEither lifts a synchronous Either step for you.