Skip to content

Migration from 1.x.x to 2.x

Damien Caselli edited this page Sep 23, 2015 · 1 revision

Add-on does not follow ember 2.x project versioning anymore, since I cannot ask people at Ember to make a release just because I made one :-)

From 2.0, handling errors changed quite a bit lot.

Please check the new config example, some things overly complicated such as cdn|version|skipCdn combo were rewritten, and some options were added such as debug.

Some people (including me at some point) were having trouble handling errors for each environment, and ended up writing pieces of code that smells simply to figure how to log errors without triggering any error:

reportError(err) {
  if (Raven /* and Raven is properly configured, and so on */) {
    Raven.captureException(err);
  } else {
    console.log(err);
    // insert unmaintainable code here
  }
}

Doing this for every error in the application is simply not satisfactory.

The best way I found so far to avoid this is to access Raven through a service that falls back to error throwing or console logging if the Raven object is not accessible.

This can happen if you're in development mode, if specified dsn is broken, or if any other unexpected stuff happened during Raven initialization.

The add-on expects you to provide a service to handle the Raven abstraction.
Filling the config.sentry.serviceName: '<the-logger-name>' will tell the plugin to inject this service as a logger property (or config.sentry.exposedPropertyName if specified) into routes, controllers, components and models.

You can of course use Ember.inject.service() for every other object that needs this dependency.

Installing ember-cli-sentry provides a generator to create the needed service:

ember g logger <the-logger-name>

// Creates app/services/<the-logger-name>.js

If no service is specified in the config, initializer will try to lookup for service:logger to resolve the injection.

This should make any this.get('logger').captureMessage('ohai') call safe enough to not juggle with conditional statements depending on the environment.

I was considering exposing the raven service instead of logger, but I believe this allows switching from|to any other logging system much more easier.

To sum up:

  1. Your config should now be updated to match the one in the README.
    Sorry for the heavy changes, but the out-of-the-box experience now feels a bit smoother.

  2. You should have a service named logger, that should extend ember-cli-sentry/services/raven.
    If you don't, you can run ember g logger logger blueprint and roll your own, or create a service that simply exposes ember-cli-sentry/services/raven.

    // app/services/logger.js
    export { default } from 'ember-cli-sentry/services/raven';
  3. Replace all if-else-whatever weird logging code by this.get('logger').captureException(/* the error */).

  4. You can safely remove jshint Raven declarations.

Clone this wiki locally