Why doesn't `fetch` reject if 400 ≤ status < 600?

[matthew-andrews]

It would be much more useful if it did, or if there were an option for it to.

[domenic]

There's a difference between an "error" and an "exception". Promise rejections parallel exceptions. But there's nothing exceptional about 4xx or 5xx errors on the web.

[matthew-andrews]

What definition of error, exception and exceptional are you using? As far as I knew the ECMA script spec refers to “Error Exceptions” implying a certain degree of interchangeability to me. I've never come across exception's adjective form (exceptional) in a computer science context. Not sure what you mean by that.

My understanding (please correct me if I am wrong) was that an Error became an exception when it is “thrown” — and so in this case whether a 4xx or 5xx is exceptional on the web is decided by how they are dealt with, not by, say, how commonly they occur…

Do you have a reference for “Promise rejects parallel exceptions”? If you “throw an Error” (e.g. below) that is caught by a Promise.

fetch('./my-lovely-json-endpoint')
  .then(function(response) {
    if (response.status >= 400 && response.status < 600) {
      throw new Error("Bad response from server");
    }
    return response.json();
  })
  .then(function(data) {
    console.log("got some data", data);
  });

Very happy to be persuaded otherwise — and I can see how ignoring the status keeps fetch clean and simple — but all the fetch use cases I can think of would require this sort of 400 ≤ status < 600 check. I can't imagine fetch ever being a feasible alternative to an AJAX wrapper if you have to write this level of boilerplate to make a request for some json…

[dgraham]

@matthew-andrews Here's the wrapper we're using on github.com as we migrate from jQuery to window.fetch. At least the required wrapper is much smaller than the full jQuery AJAX stack.

[annevk]

Yeah, we could have a status filter of sorts I suppose. Question is how generic that should be.

[matthew-andrews]

thinking about this more I really think that reject on 400+ statuses should have been the default behaviour, but it seems like that is a non starter. Offering it as an option, especially if that needs to be generic probably would be not a lot simpler than checking the status and throwing on >=400 manually.

@dgraham We've started using this to solve the problems we were having:-
https://github.com/matthew-andrews/fetchres

[annevk]

It's unclear to me why you think that makes sense. The body of a 400 or a 505 still carries semantic information that an application can use. And in fact <img> will happily display a 404 if that is an image.

[annevk]

Note that I did not say the option needs to be generic so I'm reopening this for now. We could have rejectHTTPErrors or some such.

[matthew-andrews]

superagent has quite an interesting alternative solution to this problem — it provides a res.ok that can be more easily checked against:-

 request
   .post('/api/pet')
   .send({ name: 'Manny', species: 'cat' })
   .set('X-API-Key', 'foobar')
   .set('Accept', 'application/json')
   .end(function(res){
     if (res.ok) {
       alert('yay got ' + JSON.stringify(res.body));
     } else {
       alert('Oh no! error ' + res.text);
     }
   });

Among other properties:-
https://github.com/visionmedia/superagent/blob/9e922cd34d70ead5ef4557c634a46153538134d5/lib/client.js#L385-409

[annevk]

That seems rather cool, although it does not have the nice property of rejecting. I could also imagine something like

fetch("...", {require:"2xx"})

[matthew-andrews]

i like both of those approaches. require is probably already overloaded as a term but i can't think of a better suggestion.

[matthew-andrews]

Been thinking about this a lot and I quite the TJ inspired solution:-

fetch('//mattandre.ws/path.json')
  .then(function(res) {
    if (res.ok) return res.json();
    return fallbackContent;
  });

I think it neatly addresses @domenic's concerns about client/server errors being unexceptional whilst adding just enough sugar to be convenient for developers to make handling these sorts of errors in a sensible way and it's backwards compatible*.

The nice property of rejecting is also limiting in a way because you might like instead of rejecting to do something else, say provide fallback content, instead.

What do you think?

* And can be easily polyfilled:-

(function() {
  var _fetch = fetch;
  fetch = function() {
    return _fetch.apply(this, arguments)
      .then(function(response) {
        response.ok = response.status < 400;
        return response;
      });
  };
}());

[annevk]

That polyfill seems incorrect. E.g. 399 should not match .ok, right? Or a 301 without a Location header?

[matthew-andrews]

Ah probably. I just wrote that more to give one idea of how to hook ok in. The fact that the actual status check needs to be more complex just further shows the need developers have for a little more help from the fetch spec.