undefined | Better HN

0 pointsinbx05y ago0 comments

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.

0 comments

Wintamute5y ago

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.

unilynx5y ago

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

j / k navigate · click thread line to collapse