Hey yall
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 model
hooks: beforeModel
, model
, and afterModel
; any exceptions thrown, including ReferenceError
s and TypeError
s, 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 Route
hooks.
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 throw error
.
What do people think of this? Do any of you use the throw error
behavior described above?