Hacker News Reader

Comment by aaomidi | Hacker News Reader

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.

I think that's part of the typescript plugin, not part of eslint core - 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.

There are many ways to get this rule, but the primary one being: https://www.npmjs.com/package/eslint-plugin-promise

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.

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...

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

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.

promise.catch(console.error) is still handling the error.

That's still a soft error. Meaning the app will continue like if nothing happened. Resulting in poisonous state.

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.

But until recently an unhandled promise failure was NOT a thrown error, and when it is it's not the error you want.

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.

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.

Lol what are you on about.

You're mixing so many different things right now.

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

> is its name 'no-floating-promises'

Yes, and I subscribe to the parent's sentiment: this rule is essential

https://github.com/typescript-eslint/typescript-eslint/blob/...

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!

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.

>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/issue...

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.

HNLint

Thanks!

HN should automatically detect this and let me know :D

Unfortunately I think the comment is too old to edit.

> 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.

Done! Thanks :)

Reply on news.ycombinator.com