3 ms·

Am I the only one that really dislikes the "catch" behavior? The fact that catching a promise marks it as resolved and triggers subsequent "then"s rather than

Am I the only one that really dislikes the "catch" behavior? The fact that catching a promise marks it as resolved and triggers subsequent "then"s rather than "catch"s. It means that every callback needs to be aware of every other callback and their own place in the order, so that only the last catch statement doesn't rethrow the exception. Something like $.Deferred() allows you to set 10 "fail" callbacks independently, which helps a lot when the original promise is generated by a deeply nested method and different stages of the chain add their own handling.

WorldMaker 9y ago
The catch behavior mirrors try {} catch {} blocks. If you don't need a catch, don't catch, and let it bubble up. Try to keep the things you catch to a bare minimum. The rethrow decision is largely the same for Promises as try {} catch {} blocks, too. (It's more apparent too in the async/await space where catch is even literally try {} catch {}.)
- semperdark 9y ago
  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.
Tarean 9y ago
That is assuming that you chain promises like a .then(b).catch(bhandle) .then(c).catch(chandle) instead of a .then(aout => b(aout).catch(bhandle)) .then(bout => c(bout).catch(chandle)) which admittedly is pretty ugly in javascript.

WorldMaker 9y ago

The catch behavior mirrors try {} catch {} blocks. If you don't need a catch, don't catch, and let it bubble up. Try to keep the things you catch to a bare minimum. The rethrow decision is largely the same for Promises as try {} catch {} blocks, too. (It's more apparent too in the async/await space where catch is even literally try {} catch {}.)

semperdark 9y ago
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.

Tarean 9y ago

That is assuming that you chain promises like a .then(b).catch(bhandle) .then(c).catch(chandle) instead of a .then(aout => b(aout).catch(bhandle)) .then(bout => c(bout).catch(chandle)) which admittedly is pretty ugly in javascript.