3 ms·

Thanks for the reply. I guess my contention as someone just starting to use vanilla promises is that it feels like try/catch isn't the appropriate metaphor to u

Thanks for the reply. I guess my contention as someone just starting to use vanilla promises is that it feels like try/catch isn't the appropriate metaphor to use here. In my specific case I'm passing a lot of promises to user-made scripts. then/catch seems to make things more brittle. As I said though, I'm new to them.

WorldMaker 9y ago
That's totally fair. There are learning curves involved and sometimes tradeoffs aren't entirely obvious why they were made. If you get a chance, particularly play with async/await code somewhere. There's a lot of misconception that async/await replaces Promises or is very different from Promises, but the reality is much closer that Promises were a necessary building block for async/await, and some of the trade-offs in Promise design are there to support async/await, based on work that had already been done in other languages. Maybe if you try to write some of your work as async/await it might give you insights into your architecture and how to make it feel less brittle.