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?