Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catch does not return Error #255

Closed
reggi opened this issue Mar 2, 2016 · 3 comments
Closed

Catch does not return Error #255

reggi opened this issue Mar 2, 2016 · 3 comments

Comments

@reggi
Copy link
Contributor

reggi commented Mar 2, 2016

Why does catch return an object and not an error object?

@mzabriskie
Copy link
Member

This is how it is done with Angular's $http, which this library is based on. More or less it's an artifact and not necessarily the right way to do things. I would like to move to a more consistent error path where an Error is used that has response details attached if relevant.

function createError(message, details) {
  var err = new Error(message);

  Object.keys(details, function (key) {
    err[key] = details[key];
  });

  return err;
}

createError('timeout of ' + config.timeout + 'ms exceeded', {
  code: 'ECONNABORTED',
  config: config
});

I would also like to change the lib to only reject the Promise when an actual error occurs, regardless of HTTP status code. Whereas now anything outside the 200-300 range is rejected.

@MarkHerhold
Copy link

@mzabriskie
You could also consider the use of a config flag to determine what action to take when a non 2xx/3xx response is returned.

The request-promise lib uses the simple flag/option for this. When simple is true, request-promise rejects on non-network errors (2xx, 3xx). When the flag is false, it rejects nothing and becomes the user's responsibility. I've found this to be very useful and have applications that use both settings. I think I commonly have simple set to true as it is generally a better default IMO.

https://github.com/request/request-promise#get-a-rejection-only-if-the-request-failed-for-technical-reasons

@nickuraltsev
Copy link
Member

Closing as duplicate of #24

@axios axios locked and limited conversation to collaborators May 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants