wrapError stripping ampersand-sync's err.message.

[EvanCarroll]

function wrapError is stripping ampersand-sync's err.msg. This is unfortunate as accessing it is often necessary. What about a patch to add the original contents of the err.message as options['ampersand-sync-error'] (setting that to arguments[2])?

[pgilad]

This might be fixed by new &-sync version. Can you verify?

[EvanCarroll]

I'm not sure how it could be.. We're calling options.error in ampersand-sync like this

options.error(resp, 'error', message);  // so the CB's third positional argument is *very* important.

Now, wrapError is defined like this...

var wrapError = function (model, options) {
    var error = options.error;
    options.error = function (resp) {
        if (error) error(model, resp, options);
        model.trigger('error', model, resp, options);
    };
};

But that's expecting a totally different signature. It's assuming our options.error = function (model, resp, options) {}

What if we want to get access to ampersand-sync's message?

{
  // this is how it would look if we were submitting options.error
  // straight to ampersand sync for use.. (no wrapError)
  // and we wanted to debug with options.message
  options: function (resp, errorOrSucess, messsage) {
    console.log("Error message is "+ message")
  }
}

We can't.. What we want is something like this...

var wrapError = function (model, options) {              
    var error = options.error;                           
    options.error = function (resp) {
        options['ampersand-sync-error'] = arguments[2];
        if (error) error(model, resp, options);
        model.trigger('error', model, resp, options);
    };
};

Which is what my local forked copy does... Or, change the signature.. We just barely document the error callback anyway..

save accepts success and error callbacks in the options hash, which will be passed the arguments (model, response, options). If a server-side validation fails, return a non-200 HTTP response code, along with an error response in text or JSON.

Our callback should either

• Accept ampersand-sync's message as a positional argument
• Stuff ampersand-sync's message into options or something so we can access it.

[pgilad]

Thanks for the detailed response. I believe most things here are modeled after Backbone:
https://github.com/jashkenas/backbone/blob/master/backbone.js#L1884-L1890

Does resp not contain the error and/or the error message?
Would you consider submitting a failing test case PR for this?