Throw error on error and data property be defined

[Noahkoole]

Description

Currently when a request fails it fills the error property and leaves the data property undefined. It would be a very nice feature if you could throw an error on error which in turn then makes the data property always defined. This implementation matches Axios. Currently I want to transition to openapi-fetch from axios but this change breaks a lot of code as I rely on try catch statements

Proposal

A option in the config of createClient where you can toggle if you want to throw an error rather then return the error value.

Checklist

• I’m willing to open a PR for this (see CONTRIBUTING.md)

[JeanRemiDelteil]

This means a big change in the library usage.

In our case, I just have a guard to check if there is an error, typescript is able to infer that data is not undefined.
=> The current usage is easier to use with async/await I think.

  function listOrders() {
    const { data, error } = await api.POST('/api/pets_shop/order/list', {});

    if (error) {
      // Manage error.
      console.error('Error listing orders', error);

      return [];
    }

    // Use data
    return data.data.map(deserialize);
  }

Just as a quick fix you could have a helper function that does this for you, keeping the behavior from axios.
You can also adjust this to work with promise directly,

const dataOrThrow = <TData, TResponse, TError>(apiResponse: {
  response: TResponse;
  data?: TData;
  error?: TError;
}): {
  data: TData;
  response: TResponse;
} => {
  if (apiResponse.data === undefined) {
    throw apiResponse.error ?? new Error('No data');
  }

  return {
    data: apiResponse.data,
    response: apiResponse.response,
  };
};

// Usage
try {
   const { data: _d, response } = dataOrThrow(await api.POST('/api/pets_shop/order/list', {}));
} catch (error) {
   console.error(error);
}

[jlost]

To me this seems like the more conventional behavior and it's odd that it isn't the default.

[drwpow]

It’s intentionally the design that this library doesn’t throw an error to match the fetch spec. This is intended to be lower-level and flexible. The docs have a simple example on how to throw on every error with middleware.

Though I’m strongly against changing the default behavior, I wouldn’t mind this being an option on createClient as a nice quality of life improvement over having to create middleware just for this purpose (but people likely still would reach to middleware for more advanced logging etc)