node-fetch: More easily checkable errors

Would you be open to a pull request that creates more specific errors than just Error. If I remember correctly the whatwg-fetch spec leaves errors up to implementations to decide how to handle so I think we should be free to do what we want…

It would be really helpful if there was something like a FetchError for all errors (although a different type per error would be OK too) so we can do things like

var fetch = require('node-fetch');
var FetchError = require('node-fetch').FetchError;

fetch('https://time.out/error')
  .catch(function(err) {
    if (err instanceof FetchError) {
      // send the failure to our metrics system but don't raise it as a fault
    } else {
      // send the error to our error aggregation system
    }
  });

About this issue

Original URL
State: closed
Created 9 years ago
Reactions: 2
Comments: 21 (8 by maintainers)

Commits related to this issue

fix question mark stripped from url when no params are given (#7… (#782) * fix question mark stripped from url when no params are given (#776) * add more tests * whitespace * modify the serv... — committed to node-fetch/node-fetch by xxczaki 4 years ago

Most upvoted comments

I just read https://github.com/whatwg/fetch/issues/25 and the security argument makes no sense to me because someone with bad intentions could just use curl or some other networking tool to find out more details.

I’d like to encourage you to focus less on 100% compatibility with an unfinished standard, and more on providing a viable alternative to https://github.com/request/request 😃

I like the proposed approach of adding a code property to the error because it is such a limited departure from the standard.

pekeler on Apr 2, 2016

I have updated an error handling doc for this purpose in v1.6.3:

https://github.com/bitinn/node-fetch/blob/master/ERROR-HANDLING.md

bitinn on Sep 26, 2016

@pekeler the idea of Fetch is user shouldn’t know why it failed (due to security), user should just know that it failed. So our custom error message is really for human troubleshooting, not machine processing. I am not against making it machine readable, but it will most definitely be against Fetch Spec. If you have a better suggestion, please move it to #8 😃

bitinn on Apr 2, 2016

Yes, checking the error message sucks.

network timeout at: http://10.255.255.1
request to http://10.255.255.1 failed, reason: connect ETIMEDOUT 10.255.255.1:80
request to http://this.defninitelydoesnotexist.ca/ failed, reason: getaddrinfo ENOTFOUND this.defninitelydoesnotexist.ca this.defninitelydoesnotexist.ca:80
maximum redirect reached at: http://localhost:8081/api/test/redirect

The important keywords (timeout, ETIMEDOUT, ENOTFOUND, max-redirect) are all at different positions in the message, which makes parsing more complicated than it could be.

Could we just add a code property to the error object, similar to https://github.com/request/request?

pekeler on Apr 2, 2016