Proposal: wrap all Ember.run's in `Ember.handleErrors`

This came up surrounding some discussion in Disabling promise-swallowing-ness of Route `model` hooks - #8 by machty

It’s not the most well-known feature in Ember that you can provide an error handling function as Ember.onerror which will be called whenever exceptions are thrown from your app. This gives you a place to track errors, report to the server, etc., and is one of the tools you have to seal-proof an Ember app.

Right now, Ember wraps all UI events (click handlers, etc) in handleErrors. This will catch any errors that throw synchronously from any code that runs as a result of the UI event, including stuff in run loop queues, but if you schedule something to happen later via something like Ember.run.later, or if you make use of some js lib that makes use of callbacks, even if you wrap the callbacks in Ember.run, it won’t be wrapped in handleErrors.

So it seems like making Ember.run call handleErrors makes sense here; the only complication is that for something like Ember.run.later, which delegates to backburner to eventually fir the callback, it seems like we’d need to make some property on backburner settable for wrapping its callbacks in error handlers.

Does my logic here make sense? Is there some other thing I’m not thinking of?

There is some relevant discussion on this github issue: https://github.com/emberjs/ember.js/issues/3401

I agree that Backburner definitely needs to expose a exception-trapping API. It’s the only place that I can’t already work around Ember to trap every possible exception.

The other workarounds I use right now are to register RSVP.configure('onerror',...), and to put an error action handler on the application route. (Which is why I don’t like your proposal to make route hook exceptions stop reporting as error actions, unless Ember.onerror is going to fill the gap).