Reply to @Josh-Cena

I thought about the object API (which I mentioned in the linked issue), but I now don't like it. It creates a lot of "dubious combinations", for example you would never want { default: "always", inTryCatch: "never" }.

Then remove the possibilities that don't make sense from the types (assuming "never" is deprecated):

type Options = "always" | {
  default: "always" | "ignore" | "never",
  // inTryCatch: "always", // not even necessary because you can't disable it
  inArrowFunctionShorthand?: "ignore" | "never",
}

In the future, there could be more conditions added. For example, someone might want to use "always" but make an exception for single-line arrow functions to make them less noisy:

You should either not mark it as async (which is even less noisy), or add the await. I don't think we should accommodate that style as that's not really the spirit of this rule.

This was just an example of how it would look if the rule had to be extended again.

But if we assume we never want another modifier then all we are left with is just:

type Options = 
  | "always"
  | { default: "ignore", /* inTryCatch: "always" */ }
  | { default: "never", /* inTryCatch: "always" */ }

Which could be simplified to just "always" | "ignore-or-in-try-catch" | "never-or-in-try-catch"
or just "always" | "prefer-ignore | "prefer-never".

@kirkwaiblinger maybe use one of these names in your PR? And even make an alias for the current "in-try-catch"

TLDR; IMO we should not change the rule structure unless/until there are other concrete options added to the rule.

The way I, personally, see the rule for now is that, after #9364, it should always enforce return await in error handling scenarios.

We have two stylistic choices

• prefer return await promise ("always")
• prefer return promise ("in-try-catch")

As for the other options, we have

• a stylistically unopinionated config which is a concession in order to be able to add the rule to a preset ("error-handling-correctness-only"), but not something we actually want people to use.
• A deprecated, IMO harmful option, which we can omit from this conversation ("never")

So, that gives us three options states that we need to think about. I do not believe that there is a benefit to restructuring to an options object to support just those options.

If a concrete proposal for an option is created and accepted, I think that switching to an object-based options structure (with aliases to avoid breaking changes) may well be a viable solution. But IMO that needs to exist first, before it's worth considering this issue.

(I acknowledge that my current position may appear at odds with some of my previous comments referenced in the issue report. The context around why I considered that idea at the time has changed, and so has my opinion. I don't mean to pull the rug out from under @phaux 🙂)

I agree. The current three choices: always, in-try-catch, in-try-catch-only (?) correspond to default: "always" | "never" | "ignore", but the whole premise of this proposal is that people want to handle concise arrows differently, and that needs to be proposed separately, as I don't think that's a nice convention to enforce.

Closing for now, but I would invite this to be reopened/refiled if a concrete option proposal is created as discussed.