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 using Error objects as Promise rejection reasons (prefer-promise-reject-errors) #777

Closed
feross opened this Issue Feb 8, 2017 · 1 comment

Comments

1 participant
@feross
Copy link
Member

feross commented Feb 8, 2017

This rule aims to ensure that Promises are only rejected with Error objects.

It is considered good practice to only pass instances of the built-in Error object to the reject() function for user-defined errors in Promises. Error objects automatically store a stack trace, which can be used to debug an error by determining where it came from. If a Promise is rejected with a non-Error value, it can be difficult to determine where the rejection occurred.

http://eslint.org/docs/rules/prefer-promise-reject-errors

Rule:

prefer-promise-reject-errors: "error"

@feross feross added the enhancement label Feb 8, 2017

@feross feross added this to the standard v9 milestone Feb 8, 2017

feross added a commit to standard/eslint-config-standard that referenced this issue Feb 9, 2017

@feross

This comment has been minimized.

Copy link
Member Author

feross commented Feb 9, 2017

This will be part of standard v9. Only one repo was affected, and it contained code like this:

if (typeof travisConfig.node_js === 'undefined') {
  logger.error('node_js field not found in travis configuration')
  return Promise.reject()
}

Rejected promises should contain reasons, or they are very difficult to debug. That line should be:

return Promise.reject(new Error('node_js field not found in travis configuration'))

@feross feross closed this Feb 9, 2017

feross added a commit to standard/eslint-config-standard that referenced this issue Feb 9, 2017

@lock lock bot locked as resolved and limited conversation to collaborators May 10, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.