Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

require-throws: false positive in async function #722

Closed
regseb opened this issue May 1, 2021 · 2 comments
Closed

require-throws: false positive in async function #722

regseb opened this issue May 1, 2021 · 2 comments

Comments

@regseb
Copy link

regseb commented May 1, 2021

Expected behavior

Do not report require-throws when a throw is added in an async function (because the function returns a rejected promise).

Actual behavior

If an async function contains a throw, ESLint report require-throws rule:

/home/regseb/testcase/index.js
  1:1  error  Missing JSDoc @throws declaration  jsdoc/require-throws

✖ 1 problem (1 error, 0 warnings)

ESLint Config

{
  "plugins": ["jsdoc"],
  "parserOptions": {
    "ecmaVersion": 2017
  },
  "rules": {
    "jsdoc/require-throws": 2
  }
}

ESLint sample

/**
 */
async function foo() {
  throw Error("bar");
}

Environment

  • Node version: 14.16.1
  • ESLint version: 7.25.0
  • eslint-plugin-jsdoc version: 33.0.0
@brettz9
Copy link
Collaborator

brettz9 commented May 1, 2021

A function with the async keyword will never be able to have throws, but I think it is meaningful to have a means of documenting the types that are rejected.

FWIW, TypeScript assumes "any" type for the rejected value, even while allowing the resolved value to be specified. Barring such a convention for specifying the rejected value, I think we need to allow for a means of requiring that the rejected value be documented.

There could admittedly be ambiguity in functions which are only async in having an @async tag, but which are regular functions which may throw synchronously as well as perform some async behavior (which may reject), but without a convention, I think it is better for this function to require the error types be documented, and consumers will just have to know that "throws" here refers to the rejection type given that the function is async.

We could potentially add config to prevent this, however.

@gajus
Copy link
Owner

gajus commented Jun 19, 2021

🎉 This issue has been resolved in version 35.3.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants