Promises are a lovely abstraction embraced by much of Ember API, but it’s well-known that the promise-swallowing behavior within promise callbacks can be cumbersome to debug since rather than breaking right where an exception is thrown, the exception is caught and then treated as a rejecting promise.
The way this most commonly bites in an Ember setting is within the
Route class’s various
afterModel; any exceptions thrown, including
TypeErrors, get “swallowed” and treated as rejecting promises due to the (somewhat surprising to some) fact that these hooks are called within one giant internal promise chain. Even though the error that gets passed to rejection handlers often has enough information for you to debug and see where the error is occurring (via the error’s
stack property among others), it’s a much much better experience to actually break right where the error happens so that you can inspect variables, etc.
So anyway, I’m strongly considering the idea of making those
Route hooks not swallow errors synchronously thrown from those hooks. I spiked on this a bit earlier and here’s a demo of it working: http://jsbin.com/ucanam/1556/edit
Here’s the router.js PR for this: https://github.com/tildeio/router.js/pull/56
Note that I’m not changing anything about how errors are treated within promises in general; just within
I highly doubt people willfully were synchronously throwing exceptions from
model hooks with the intent of them being treated as rejecting promises; the very few that did would have to change their code to
return Ember.RSVP.reject(error) instead of
What do people think of this? Do any of you use the
throw error behavior described above?