Comment 9 for bug 1286611

If there's an exception thrown while an instance is constructed through a call to "new", this exception will unwind the stack and the "new" call will never terminate. Thus no field or variable will be assigned anything.

You talk about a risk from uninitialized variables. But you must understand that there are very few cases, if any, in our code where this could even happen (though I can't speak much about some of the third party code that's part of the Ember source code).
See, when an exception is thrown it's either handled locally, because it was somewhat expected, through a try...catch statement, or it's not. In the case that it's not it's in almost all cases because there's no real simple way to handle it. Mainly because the exception puts the application in an invalid state. What we then do is to let the exception percolate upwards to a place where the subsystem from where it originated can be terminated, thus putting the application back in a valid state. If that's not possible (like with what I mentioned about exceptions in the EmberServices constructor) the whole process is shut down.

Could you point to any place in the source code where there would be an invalid state in a field if there was an exception thrown?