You might not need jQuery (2014)

Re:You might not need jQuery (2014) by inbx0 on Thursday January 14, 2021 @04:31AM (#25774140)

Your fetch examples don't reject the promise if the server responds with error status code, like 404, which is probably not what you'd want. You'd need to handle that separately with something like

    const resp = await fetch('/my-url')
    if (!resp.ok) throw new Error(await resp.text())
    const data = await resp.json()

From MDN (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API):

> The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.

[ Parent | on HN ]

Re:You might not need jQuery (2014) by Wintamute on Thursday January 14, 2021 @07:31AM (#25775589)

I know this pattern and have used it myself. The problem is though, that generally you should only throw an error when you reach an exception - it's like saying "I don't know what to do next", and you defer that decision up the stack.

Is a request that technically succeeds (the response has come back), but has a status code where the server has indicated something didn't work always an _exception_ in your client code? I'd argue it isn't, and should just be handled in the normal control flow of your client code via conditionals.

[ Parent | on HN ]

Re:You might not need jQuery (2014) by unilynx on Thursday January 14, 2021 @11:21AM (#25778203)

The answer probably depends a lot on what you're used to from other languages.

Java users might want to make 404 an exception (FileNotFoundException), C++ users probably wouldn't throw an exception for that

[ Parent | on HN ]