Improve error format consistency

[cbetta]

Currently errors come in either as:

• The error object in a callback, with a message attributes
• The error object in a callback, with a error-code and error-code-label attribute
• The response object in a callback, with a status attribute with a value of 0

This is causing a lot of headache when used (see nexmo/nexmo-cli#104).

I propose we instead return an error object and only an error object if an error occurred, and a response object and only a response object if no errors occurred. This would also bring the library more in line with how Promises work down the line if we want to go that way.

[cbetta]

@leggetter can we close this now, based on the 2.0 release?

[leggetter]

@cbetta I thought we could assess this as part of https://github.com/Nexmo/nexmo-cli/issues/123

Based on the above:

The error object in a callback, with a message attributes

If message is present on the body response it will be available via error.body.message. But not across all APIs.

The error object in a callback, with a error-code and error-code-label attribute

Available via error.body['error-code'] etc. But I'd want to check to see what happens if we get a 2xx response. It may be that we don't make a callback with an error.

The response object in a callback, with a status attribute with a value of 0

I don't think we expose the response object. We just expose the success result.

[cbetta]

@leggetter ok, I will evaluate!

[soullivaneuh]

This one is quite crazy IMO. If I follow the TS API you made, I should implement the verify API that way:

nexmo.verify.request({
  number: phoneNumber,
  brand: 'Company',
  code_length: '4'
}, (err: VerifyError, data: RequestResponse) => {
  if (err) {
    console.log('error:', err);
    throw new Unavailable('test', err);
  }

  console.log('result:', data)
});

Here VerifyError contrains the status and the error_text fields.

But If I try this with bad credentials for example, I have the error... on the data object. :thinking:

To me it's a bug as this does not respect the typescript interface.

Am I right?

[kellyjandrews]

Thanks for this @soullivaneuh - I will take a look at this soon and let you know what I can figure out. I'm currently working through some old issues and catching up with the status of the SDK. Thanks again!

[manchuck]

@cbetta If you update to V3, we are throwing errors as we have migrated to using promises. This should no longer be an issue for you.

[cbetta]

Tnx for the update after 6 years 😂

[pardel]

@cbetta better late than never ;)