| 13:30 | <snek> | i wish there was a promise method like finally except it didn't propagate the exception and didn't mark the promise as "handled" |
| 13:30 | <snek> | does anyone else wish this |
| 16:57 | <Ashley Claymore> | what would it return? |
| 17:01 | <Ashley Claymore> | (when the promise was rejected) |
| 22:24 | <snek> | what would it return? |
| 22:25 | <snek> | basically add the argument as a fulfill and reject handler, but don't create a new promise or update [[PromiseIsHandled]] |
| 22:37 | <ljharb> | why? |
| 22:44 | <snek> | idk this is a thing i find myself wanting to do a lot when writing apis |
| 22:51 | <kriskowal> | When it comes to unhandled rejections, there are two reasonable design families and everything has somehow chosen the third. Every unhandled rejection is potentially eventually handled until post mortem finalization. From a debugging point of view, you either want silence (so real errors are not lost in noise errors) or interactivity. An interactive promise debugger shows you both “currently unhandled rejections” and “currently pending promises”, because both of these are ephemeral but at a moment in time might suggest a defect, either a forever-pending promise or never-handled-rejection. |
| 22:51 | <kriskowal> | But lint rules for no-dangling-promises are good. |
| 22:52 | <kriskowal> | Returning promises in callbacks that dangle the promise is bad. |
| 22:52 | <kriskowal> | Like, the convenience of addEventListener('click', async() => {}) is undeniable, but still wrong. The promise should get sunk, or verified to be unrejectable statically. |
| 22:54 | <kriskowal> | I did have a version of Q instrumented for a prototype Chrome extension that could give you the traces for all still-pending and still-unhandled promises. I do hope that idea makes its way to a nearby devtools. |
| 22:55 | <kriskowal> | In the case of a CLI with no devtools attached, it’s very reasonable to defer reporting unhandled rejections until collection. |
| 22:59 | <kriskowal> | On the other hand, I’m torn regarding “send-only” promise handlers. In Q, then was not the bottom of the protocol, it was implemented in terms of done, which would register optional callback and optional errback, but didn’t create and return a composite promise. The expectation was that the callback and errback returned void. And the thenable protocol doesn’t actually expect more than the behavior of done, so you can write less wasteful promise handling. |
| 23:00 | <kriskowal> | But having both the then tower and the done or “then-only” tower implies a lot more combinators. |
| 23:05 | <kriskowal> | In a more static language, you could have your cake and eat it, generating runtime variants of the promise-returning function that do and do not actually bother creating or returning the promise, ad nauseam. |
| 23:09 | <ljharb> | can't you return the promise with .then() on it, and that promise will be unhandled? |