1

I am implementing error logging in my EmberJS application much as is described here and it's working pretty well. The only part that is throwing me off is how to properly handle error calls from the Ember RSVP onerror event.

Errors produced from within the Ember run loop are nicely formatted with message and stack properties, but errors raised from RSVP give back a standard XHR response and no additional context. Is it possible to access any information about what Ajax call was being executed when this error occurred?

I am using Ember 1.3.1 and Ember Data 1.0.0+b6.

Matt Baker
  • 3,394
  • 3
  • 25
  • 35
  • What do your ajax calls look like and how to you resolve the success/error hooks? – Alex Lynham Jan 31 '14 at 11:44
  • @AlexLynham I'm not making direct Ajax calls, Ember Data handles all that. – Matt Baker Jan 31 '14 at 11:51
  • My guess is it's something to do with how RSVP resolves the ajax promise and how you can handle the values returned from that. – Alex Lynham Jan 31 '14 at 12:29
  • Conversation with the Ember Data team here: https://github.com/emberjs/data/issues/1727 – Matt Baker Jan 31 '14 at 16:53
  • Ahh, I'm with you. So the standard XHR Ajax error object isn't giving you enough to debug with? What is your baseline (ideal scenario) for getting a more helpful log? Some kind of stack trace detailing exactly at what point the error happened? – Alex Lynham Feb 02 '14 at 17:59
  • @AlexLynham ideally, yes, but it sounds like call stack stitching between the Ajax caller and promise finish is a feature the browsers will have to implement. In the meantime I just create my own error object using the status and response text as my message. It's not ideal since I lose the first half of the call stack, but I'd rather know an error is occurring with partial context than none at all. – Matt Baker Feb 03 '14 at 13:09
  • That sounds familiar. In doing an API call using an Ember app I ended up abandoning getting a more useful stack and just mixing a combination of the Ember promise and API status into an object. Not perfect, but eh. – Alex Lynham Feb 03 '14 at 14:20
  • This likely should be addressed within ember-data, rather then rejecting with the jqXHR it could craft a more useful Error – Stefan Penner Mar 02 '14 at 03:22
  • that being said, RSVP is only passing you the reason the ajax operation failed, but the reason originates in jQuery. – Stefan Penner Mar 08 '14 at 15:25

1 Answers1

0

I'm using a dirty workaround to get context from RSVP internals. You can overwrite RVSP.Promise._onerror method and include some data. 'this' object has _label property which contains sometime useful info about model. My solution is still not ideal but it is something. 

#RSVP _onerror hack
#put this before creating application
oldMethod = Em.RSVP.Promise.prototype._onerror
Em.RSVP.Promise.prototype._onerror = (reason) ->
  reason.label = this._label
  oldMethod(reason)

App = Ember.Application.create(options)

And little improved code to hook on standart onerror method 

 Ember.RSVP.configure('onerror', (error) ->
   #handle situation when user in other tab logout from application.
   if error.status == 401 #not authorized
     window.location = '/login'
   else
     niceError = unless error.stack
       message = {
         label: error.label,
         status: error.status,
         statusText: error.statusText,
         state: error.state(),
         readyState: error.readyState,
         responseText: error.responseText.replace(/<(?:.|\n)*?>/gm, '').substr(0,100)
       }
       new Error(Ember.inspect(message))
     else
       error

 #here is method to send notification about error
 MessageApp.errorHandler('RSVP', niceError)
piotrze
  • 479
  • 5
  • 14