5 ms·

There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule. So many bugs in the JS world is because of d

There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule. So many bugs in the JS world is because of dangling promises.

ausjke 7y ago
hundreds of rules to read, is this on its recommended list if it's so critical? is its name 'no-floating-promises'?
- williamdclt 7y ago
  > is its name 'no-floating-promises' Yes, and I subscribe to the parent's sentiment: this rule is essential
  - brycelarkin 7y ago
    https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md https://github.com/typescript-eslint/typescript-eslint/blob/...
- aaomidi 7y ago
  It's unfortunately not on the recommended list. For very few circumstances the rule doesn't make sense, but most of the time that shows bad programming design. That's the name!
- johnsoft 7y ago
  >is this on its recommended list Not now, but it's planned to be starting with the next major version. They are holding off until then since changing the default rules is considered a breaking change. https://github.com/typescript-eslint/typescript-eslint/issues/1423 https://github.com/typescript-eslint/typescript-eslint/issue...
- aaomidi 7y ago
  I also highly recommend just reading all the rules if you're a JS/TS developer. It really helps you see what stuff could be very useful.
z3t4 7y ago
If you add a catch block it will be even worse, all errors inside a promise callback will then become soft errors. Only add the catch if you actually plan to handle the error.
- hombre_fatal 7y ago
  promise.catch(console.error) is still handling the error.
  - z3t4 7y ago
    That's still a soft error. Meaning the app will continue like if nothing happened. Resulting in poisonous state.
zymhan 7y ago
We use Pulumi and Typescript, and it seems to rely heavily on Promise. I wonder how that ESLint rule would affect Pulumi code? https://www.pulumi.com/docs/intro/concepts/programming-model/#outputs https://www.pulumi.com/docs/intro/concepts/programming-model...
- dfee 7y ago
  I’m not sure on Pulumi specifically, but a .catch on a non-awaited promise should be fine.
nfriedly 7y ago
I think that's part of the typescript plugin, not part of eslint core - https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md https://github.com/typescript-eslint/typescript-eslint/blob/... (I assume that means it only works on TypeScript.) But, I agree with your point, that rule can catch a lot of bugs.
- krainboltgreene 7y ago
  There are many ways to get this rule, but the primary one being: https://www.npmjs.com/package/eslint-plugin-promise https://www.npmjs.com/package/eslint-plugin-promise
  - vimslayer 7y ago
    I don't think that plugin catches floating promises, i.e. promises that are not waited (either via await or then/catch method). The rules listed in that package's readme don't seem to mention it at least (unless I'm totally misreading something). You kinda need TypeScript for that because you need the type info to know if a value whether some value is a Promsie to give the warning.
tengbretson 7y ago
I can't speak to the front-end, but there are plenty of situations in dealing with node where the correct thing to do is to throw a fatal error. If you have properly setup handlers for the end of the process lifecycle I don't see what the problem is.
- ergothus 7y ago
  But until recently an unhandled promise failure was NOT a thrown error, and when it is it's not the error you want.
  - z3t4 7y ago
    There is a saying - what you don't know can't hurt you. The idea of Promises comes from strongly typed static functional languages. Adding it to JavaScript was a terrible idea. Like with static modules - forcing the user to download the whole website/app before anything is rendered on the screen.
    - aaomidi 7y ago
      Lol what are you on about. You're mixing so many different things right now.
  - tengbretson 7y ago
    Absolutely! I guess what I'm trying to say is that in my experience, crashing on an unhandled rejection is a better remedy to the dangling promise problem than banning them outright.
dang 7y ago
Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- edflsafoiewq 7y ago
  HNLint
- aaomidi 7y ago
  Thanks! HN should automatically detect this and let me know :D Unfortunately I think the comment is too old to edit.
  - dang 7y ago
    > HN should automatically detect this and let me know That's on the list! I've reopened the comment for editing if you still want to.
    - aaomidi 7y ago
      Done! Thanks :)

There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule. So many bugs in the JS world is because of dangling promises.

ausjke 7y ago

hundreds of rules to read, is this on its recommended list if it's so critical? is its name 'no-floating-promises'?

williamdclt 7y ago
> is its name 'no-floating-promises' Yes, and I subscribe to the parent's sentiment: this rule is essential
- brycelarkin 7y ago
  https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md https://github.com/typescript-eslint/typescript-eslint/blob/...
aaomidi 7y ago
It's unfortunately not on the recommended list. For very few circumstances the rule doesn't make sense, but most of the time that shows bad programming design. That's the name!
johnsoft 7y ago
>is this on its recommended list Not now, but it's planned to be starting with the next major version. They are holding off until then since changing the default rules is considered a breaking change. https://github.com/typescript-eslint/typescript-eslint/issues/1423 https://github.com/typescript-eslint/typescript-eslint/issue...
aaomidi 7y ago
I also highly recommend just reading all the rules if you're a JS/TS developer. It really helps you see what stuff could be very useful.

z3t4 7y ago

If you add a catch block it will be even worse, all errors inside a promise callback will then become soft errors. Only add the catch if you actually plan to handle the error.

hombre_fatal 7y ago
promise.catch(console.error) is still handling the error.
- z3t4 7y ago
  That's still a soft error. Meaning the app will continue like if nothing happened. Resulting in poisonous state.

zymhan 7y ago

We use Pulumi and Typescript, and it seems to rely heavily on Promise. I wonder how that ESLint rule would affect Pulumi code? https://www.pulumi.com/docs/intro/concepts/programming-model/#outputs https://www.pulumi.com/docs/intro/concepts/programming-model...

dfee 7y ago
I’m not sure on Pulumi specifically, but a .catch on a non-awaited promise should be fine.

nfriedly 7y ago

I think that's part of the typescript plugin, not part of eslint core - https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md https://github.com/typescript-eslint/typescript-eslint/blob/... (I assume that means it only works on TypeScript.) But, I agree with your point, that rule can catch a lot of bugs.

krainboltgreene 7y ago
There are many ways to get this rule, but the primary one being: https://www.npmjs.com/package/eslint-plugin-promise https://www.npmjs.com/package/eslint-plugin-promise
- vimslayer 7y ago
  I don't think that plugin catches floating promises, i.e. promises that are not waited (either via await or then/catch method). The rules listed in that package's readme don't seem to mention it at least (unless I'm totally misreading something). You kinda need TypeScript for that because you need the type info to know if a value whether some value is a Promsie to give the warning.

tengbretson 7y ago

I can't speak to the front-end, but there are plenty of situations in dealing with node where the correct thing to do is to throw a fatal error. If you have properly setup handlers for the end of the process lifecycle I don't see what the problem is.

ergothus 7y ago
But until recently an unhandled promise failure was NOT a thrown error, and when it is it's not the error you want.
- z3t4 7y ago
  There is a saying - what you don't know can't hurt you. The idea of Promises comes from strongly typed static functional languages. Adding it to JavaScript was a terrible idea. Like with static modules - forcing the user to download the whole website/app before anything is rendered on the screen.
  - aaomidi 7y ago
    Lol what are you on about. You're mixing so many different things right now.
- tengbretson 7y ago
  Absolutely! I guess what I'm trying to say is that in my experience, crashing on an unhandled rejection is a better remedy to the dangling promise problem than banning them outright.

dang 7y ago

Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

edflsafoiewq 7y ago
HNLint
aaomidi 7y ago
Thanks! HN should automatically detect this and let me know :D Unfortunately I think the comment is too old to edit.
- dang 7y ago
  > HN should automatically detect this and let me know That's on the list! I've reopened the comment for editing if you still want to.
  - aaomidi 7y ago
    Done! Thanks :)