Reject Promise on Error Response

[TejasQ]

The Issue

I find working with this API fairly different to reason about when calling fetch and receiving an error response from an external resource. Currently, I am implementing a feature that has the following flow:

• fetch a resource with GET
• if said resource doesn't yet exist, do a new fetch call with POST
• continue doing things.

Currently, if the GET fails with a 404, the promise is not rejected and I am unable to handle the error appropriately (by creating what does not already exist).

Proposed Change

The API that I (and others on my team) imagine and would typically expect to work with is as follows:

const getMyThing = () => {
  // Try to GET it.
  fetch("https://myendpoint.com/myThing/thingName")
    // resolves! Awesome, let's process it.
    .then(thing => thing.process())
    /* 
      Error? 
      It would be nice if the rejection contained the Response, with headers and status code.
    */
    .catch(error => {
      if (error.status === 404) {

        // create it and return its promise.
        return createMyThing("thingName")
      }

      // throw the error.
      throw new Error(error)
    })
}

If this issue makes sense and is considered, I'm happy to help describe, implement or test to the best of my ability.

cc @Angarsk8 as a fellow coder with this issue.

[TejasQ]

I realize this is a dupe of #18. After reading the entire discussion there, I think it would make sense to revisit this issue since there are still developers for whom this is counter-intuitive all these years later – exception/error semantics aside, this is a relatively high-level abstraction and as such,

[annevk]

We cannot change the behavior at this point, that would break backwards compatibility. I also don't think we want to. Note that you can use thing.ok to make sure you only process something with a 2xx code.

(It also seems you didn't finish your sentence in the previous comment, but I'll point out that fetch() is not meant as a high-level abstraction. It's actually meant to be as low-level as we can go, while still providing an attractive API.)

[TejasQ]

Ah, my comment submitted before I finished it. Sorry about that! @annevk, everything you’ve said makes a lot of sense. Is there a possibility to add warnings (with detailed instructions) on server errors and how to handle them to the spec in order to better instruct newer developers?

[annevk]

@TejasQ by server error do you mean HTTP status codes? Those are documented in HTTP upon which Fetch is layered: https://tools.ietf.org/html/rfc7231#section-6.

[TejasQ]

@annevk right – I see. To clarify, I meant: in the event the Response from a fetch call has a non-2xx status, would it make sense to display a warning in the browser's console along the lines of:

The Promise from the fetch() call resolved with status (not 2xx).
To handle this error, check the `status` property of the Response object in the
`then` block of your promise chain, as `catch` is only triggered on exceptions,
not errors.

in order to make coding with fetch more approachable for newer/junior devs? Kind of documenting the API to developers on an as-needed basis alongside more comprehensive docs in the spec?

[annevk]

More documentation is planned, see #543. Help with that is appreciated. As for surfacing warnings, I think that would be up to those making the developer tools and best directly asked of them. It might be perceived as spammy as there are many legitimate reasons to get non-2xx statuses.

[TejasQ]

Great. Thanks! Happy to close this.