| 06:39 | <Riki (SIE 🇯🇵 Coordinator)> | Hi all! Riki from Sony Interactive Entertainment here 👋 🇯🇵 We’re excited to welcome TC39 back to Japan in about 3 weeks! Just a friendly reminder to fill out the In-Person Registration Form if you’re planning to attend in person. The deadline is one week from today, so please make sure to register by then! Registration is a MUST, and there may be some very serious consequences™ if you show up on the day without letting us know 👹 Looking forward to seeing everyone in Japan ♥️ |
| 14:53 | <peetk> | how about .suppress() |
| 17:15 | <James M Snell> | suppress does not come across as meaningful to me. "unhandled" is common terminology for promise rejections, making "mark as handled" fairly intuitive |
| 20:58 | <Zb Tenerowicz (ZTZ/naugtur)> | How about p.handle() defined as a then with two optional args and a void return value. Calls the right callback if present to handle, disregards its return value and doesn't create a new promise |
| 21:38 | <James M Snell> | I guess I'm just not sure why it's necessary to re-architect a simple approach that already exists |
| 21:40 | <James M Snell> | it's really literally just putting a wrapper around an existing embedder function that is already called "MarkAsHandled" https://v8docs.nodesource.com/node-25.0/d3/d8f/classv8_1_1_promise.html#a797ac702cb8e94a7bf117e9d3eeb55bc |
| 22:03 | <bakkot> | Embedder functions are generally made for convenience of a particular engine with very little thought given to their design, and are also not exposed to 99.99%+ of users. |
| 22:04 | <bakkot> | It's certainly possible for an such a thing to have landed on a good design, but there's not much reason to take them as precedent except insofar that they establish a thing is possible |
| 22:11 | <James M Snell> | Yeah I know :-) I'm just not seeing any argument that convinces me that it's not a good design? If that make sense? Like I'm seeing bike shedding but no explanation why the current approach is not ideal. |
| 22:17 | <ljharb> | i mean the current approach isn't ideal because the current reality isn't ideal. unhandled rejections are supposed to be fine. |
| 22:19 | <James M Snell> | Well, yeah.. ;-) ... accounting for that however |
| 22:23 | <bakkot> | whenever there's a proposal I think it makes sense to have a period of tossing out random related ideas before settling on a design even if there is nothing particularly wrong with the original proposal, because maybe there's something better |
| 22:23 | <bakkot> | but you have to actually spend a while playing with possibilities to know this |
| 22:23 | <James M Snell> | Fair |
| 22:27 | <James M Snell> | Let's not worry then what we call it or what the shape exactly is. Not discounting @ljharb's comments there about the situation being unfortunate, do we think there's enough of a motivation here for me to bring/ask for a Stage 1 proposal? |
| 22:28 | <ljharb> | the only (concrete) benefit over .catch(() => {}) is that a noop isn't needed? |
| 22:31 | <James M Snell> | No no-op function, no new returned promise. There's also the consideration that await p.catch(()=>{}) does not propagate the rejection to the await. But markAsHandled(p); await p; does propagate to the await still |
| 22:31 | <James M Snell> | Sure you could p.catch(...); await p; but the small footgun is still there |
| 22:33 | <James M Snell> | That's super minor but just illustrates that the whole motivation would be avoiding small footguns. They can be worked around already. This is why I'm just asking the question about whether there's enough motivation to even bring it |