{"action":"opened","issue":{"url":"https://api.github.com/repos/emberjs/ember.js/issues/12166","labels_url":"https://api.github.com/repos/emberjs/ember.js/issues/12166/labels{/name}","comments_url":"https://api.github.com/repos/emberjs/ember.js/issues/12166/comments","events_url":"https://api.github.com/repos/emberjs/ember.js/issues/12166/events","html_url":"https://github.com/emberjs/ember.js/issues/12166","id":102371579,"number":12166,"title":"Error event / substate","user":{"login":"btecu","id":7517745,"avatar_url":"https://avatars.githubusercontent.com/u/7517745?v=3","gravatar_id":"","url":"https://api.github.com/users/btecu","html_url":"https://github.com/btecu","followers_url":"https://api.github.com/users/btecu/followers","following_url":"https://api.github.com/users/btecu/following{/other_user}","gists_url":"https://api.github.com/users/btecu/gists{/gist_id}","starred_url":"https://api.github.com/users/btecu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/btecu/subscriptions","organizations_url":"https://api.github.com/users/btecu/orgs","repos_url":"https://api.github.com/users/btecu/repos","events_url":"https://api.github.com/users/btecu/events{/privacy}","received_events_url":"https://api.github.com/users/btecu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-08-21T12:42:09Z","updated_at":"2015-08-21T12:42:09Z","closed_at":null,"body":"A way to handle errors is to include an action on the route. If the errors are generic (unauthorized, forbidden, etc.) they can be handled in the application route.\r\nThis used to work perfectly and I'm not exactly sure when it broke, but probably in `1.13`.\r\n\r\nThe documentation has the following example (http://guides.emberjs.com/v1.13.0/routing/loading-and-error-substates/):\r\n```\r\nactions: {\r\n  error: function(error, transition) {\r\n    if (error && error.status === 400) {\r\n      // error substate and parent routes do not handle this error\r\n      return this.transitionTo('modelNotFound');\r\n    }\r\n\r\n    // Return true to bubble this event to any parent route.\r\n    return true;\r\n  }\r\n}\r\n```\r\n\r\n1. There is no `status` on `error` anymore. Now `error` contains an array of `errors` - which seems to be fine, but it's not inline with the documentation.\r\n2. `error.errors[0].status` is not a number but a string. This is very confusing and seems like an issue. Again, not specified in the documentation.\r\n3. It seems that no matter what you return or how you handle it, the error will still be handled somewhere else and will be logged in the console. I tested with some Ember Data errors - `401` and `404`. I do `return this.transitionTo('login');` in an occasion, but the error is still logged. If I return true, the error gets logged twice!\r\n\r\nFor the first two I could submit a pull request to update the documentation but the third one seems to possibly be an issue. Also, was the `status` change from number to string intended?"}}