Which is why you write a catch combinator to filter out only the errors you want

  function ifErr(predicate, handler) {
    return e => { if (predicate(e)) return handler(e); throw e; }
  }

  function codeIs(n) { return e => e.code == n }

  promise.catch(ifErr(codeIs(429), e => handle error here))

What treats a 429 response as an error?

XMLHttpRequest doesn't use promises, and the Fetch API treats all HTTP responses -- including 429 -- as success.

I think you have a problem with a library.

Yeah, I never said otherwise. I had jQuery.ajax [0] in mind when writing that. If I recall correctly, it rejects the promise when you get a 4XX. I haven't used it since a few years now, but I still see people handling responses incorrectly with other wrapper libs.

[0] https://api.jquery.com/jquery.ajax/

Sorry, meant to reply to parent....

But yeah...one of the several reasons I much prefer Fetch API/polyfill to $.ajax.

no, libraries should not throw exceptions if they get a http response. that is a perfect example where the programmer has to roll his own, because this is entirely situational.

the pseudo-code example of the grandparent seems to me to implement a) detecting the http code, b) throwing an exception and finally c) handling this except.

See superagent where anything that's not a 2xx is treated as an error (https://github.com/visionmedia/superagent/issues/283)

Which pseudo code are you referring to?

Exceptions being for "exceptional" circumstances is a popular misconception. Exceptions are for "an upper layer to handle". You can use them for any alternative values you wish to propagate to the upper layer.

> Exceptions are for "an upper layer to handle".

So are return values :) The difference is that return value is for the next immediate layer; an exception is for some layer, but I don't know what.

IMO your HTTP layer should not be throwing exceptions based on status code. The layer above that should.

Oh ok. Its not pseudocode, the combinators work :)

I would put it the other way around. The http layer should not decide that the layer immediately above it must be the one to handle all its errors. It should also be the one that defines the default (success) case and the error case, since those are defined by the HTTP protocol.

I didn't realize this was a point of contention. I had jQuery.ajax in mind when I wrote this, if I recall correctly they reject the promise when it doesn't receive a 2XX.

For comparison, the new fetch API resolves to a response which can have any status code.