Errors handling

#1

I found this section in Ember Guides explaining the debugging configuration.

The questions I have are:

  1. What is the right place to put the suggested code-snippet inside of app.js:
RSVP.on('error', function(error) {
  assert(error, false);
});

if the app.js already have has the following lines:

# app.js

import Application from '@ember/application';
import Resolver from './resolver';
import loadInitializers from 'ember-load-initializers';
import config from './config/environment';

const App = Application.extend({
  modulePrefix: config.modulePrefix,
  podModulePrefix: config.podModulePrefix,
  Resolver
});

loadInitializers(App, config.modulePrefix);

export default App;
  1. How is it related and is it still valid to use an initializer and put the following errors handlers in it:
# initializers/catch-all-errors.js

// Global error handler in Ember run loop
Ember.onerror = function (err) {
    console.log(err);
};

// Global error handler for promises
Ember.RSVP.on('error', function(err) {
    console.log(err);
});

based on this blog article ?

Thank you!

#2

Inside of app.js you can put it anywhere. The whole module is going to be evaluated before the app boots so it’s not very important.

Your initializer example is doing the same thing. You don’t need both.

Ember.RSVP.on(...) is an older way of saying import RSVP from 'rsvp'; RSVP.on(...);. They are the same RSVP object.

#3

Thank you for your response, @ef4. But when I use console.log(err);, Ember linter sees that as an error pointing out to the use of console statement, is it OK though?

#4

The linter rules are just suggestions, if you decide you are OK with having console statements in your code then you can turn off that rule, or use a comment to suppress the error in this one place.

I think people mostly view console.log as a temporary thing useful while debugging an issue but then removed before you commit and go to production.

1 Like
#5

@ef4 Ok, thank you very much. I got it.