Live data from Hacker News

Promises are not neutral enough

staltz.com

131–133 of 133 posts

Re: Promises are not neutral enough

#131
post #87

Earlier quoted context omitted.

If there’s no logic to catch the rejection it will be silently ignored, which is effectively the same as “swallowing exceptions” – your distinction is correct but it’s academic at best. In practice, this behavior causes very real problems and in node land they made the sane decision to kill the process whenever an unhandled promise rejection comes about. I don’t know if this has landed yet, but you’ll see a warning a…

Uncatched rejections are deprecated in Node.js. In a future version, an uncaught rejection will crash Node.js

Indeed, as I wrote in the second paragraph.

Re: Promises are not neutral enough

#132
post #87

Earlier quoted context omitted.

If there’s no logic to catch the rejection it will be silently ignored, which is effectively the same as “swallowing exceptions” – your distinction is correct but it’s academic at best. In practice, this behavior causes very real problems and in node land they made the sane decision to kill the process whenever an unhandled promise rejection comes about. I don’t know if this has landed yet, but you’ll see a warning a…

This was a problem before native Promises, but not so much anymore. Throwing on unhandledRejection has been the default in Node.js >= 7 and browsers now have DOM Levels 1 and 3 events for unhandledrejection.

This is a half truth. Native promises landed quite some time before a way to catch unhandled promises did, and even that event wasn’t enough, as evidenced by at least node deciding that the process needs to crash. (As it would’ve when unhandled exceptions were thrown.) The browser story is of course different.

Regardless, the original poster was correct – this has been a sin of promises for a long time. What’s worse I think is that because of this we move have semantics that are close but not quite the same as exceptions. Case in point: throwing an exception while executing a promise function will reject the promise. But it’s not an exception anymore, even though the value of the rejection is in fact the exception. The semantics are now different – because promises.

Promises in JavaScript have a certain almost-but-not-quite quality to them.

Re: Promises are not neutral enough

#133
post #47
post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

Hi. First I'd like to comment that I wrote that blog post literally quickly because I just wanted to convert an informal Twitter thread into a more shareable and digestible format, so I didn't take the time to make it "hackernews comment resistant" if you know what I mean. On opinionated choices: I try to base that on mathematics. When it comes to async programming, that means equational reasoning and following some…

What if we just make a Task that works the way you want Promises to work, and `run`ning it returns a Promise?
Post reply on HN