News for hackers. Stuff that matters.

A comment on Cancelable Promises: Why was this proposal withdrawn?. Parent comment

Re:Cancelable Promises: Why was this proposal withdrawn? by spion on Monday December 19, 2016 @09:20AM (#13211511)
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))
[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by paulddraper on Monday December 19, 2016 @10:32AM (#13211981)
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.

[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by TheAceOfHearts on Monday December 19, 2016 @02:47PM (#13214415)
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/

[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by paulddraper on Monday December 19, 2016 @04:59PM (#13215350)
Sorry, meant to reply to parent....

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

[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by y4mi on Monday December 19, 2016 @11:00AM (#13212203)
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.

[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by vinylkey on Monday December 19, 2016 @11:52AM (#13212748)
See superagent where anything that's not a 2xx is treated as an error (https://github.com/visionmedia/superagent/issues/283)
[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by spion on Monday December 19, 2016 @11:03AM (#13212238)
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.

[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by paulddraper on Monday December 19, 2016 @11:48AM (#13212706)
> 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.

[ Parent | on HN ]
Re:Cancelable Promises: Why was this proposal withdrawn? by spion on Monday December 19, 2016 @01:20PM (#13213589)
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.

[ Parent | on HN ]