Avoiding the throw of an ApiError for certain status codes

[olliejm]

After #282 was fixed (very promptly, thanks!), I just realised that my original intended use case - to avoid writing try/catch to deal with ApiError by setting serviceResponse: 'response' and checking status - would not work, as the generated code always throws on an error for 4xx/5xx codes.

I'm wondering if it makes sense, probably only when serviceResponse: 'response' is set, that we can optionally specify status codes which should not throw because the caller expects them.

My use case is, that in a Next.js application in several places I may make an API call and it would be convenient to be able to do something like:

export default async function Page({ params: { id } }) {
  const data = await DataService.getControllerDataById({ id });

  if (data.status === 404) {
    notFound();
  }

  return <MyDataComponent data={data.body} />;
}

I would argue that for 4xx status codes in particular, you may often expect e.g. a 404 if a URL contains an invalid or since-removed ID, or say a 429 if the server is rate-limiting. I wouldn't really consider these exceptional, but something that just determines the UI state, like going to a 404 page, doing a redirect, showing the user their form data was refused, that they aren't authorised, and so on.

For server-side 5xx status codes I think it would be more reasonable to throw by default.

Any thoughts on this? It's obviously not really a huge issue to try/catch this, but just feels a little off to me when I'm trying to handle cases I expect, and not unexpected errors.

I would propose the presence of a requestThrowStatusCodes and/or requestDontThrowStatusCodes, followed by either a) all existing throwing codes will throw by default, or b) 4xx don't throw and 5xx do throw. I realise changing default throwing behaviour would be breaking, so maybe that would also be toggled by another setting to opt-in to new defaults.

[jordanshatford]

@olliejm that sounds reasonable to me. Will need to discuss further and decide how exactly we want this to function.

Cc: @mrlubos

[mrlubos]

I see @olliejm. Frankly this might take a while to implement as we have other priorities, but would something like openapi-fetch API work for you?

[olliejm]

This is by no means a pressing concern for me as I use this library on a hobby project which I sporadically work on, and which itself has much more significant outstanding work to be done than dealing with 4xx codes. Additionally they can be handled anyway with try/catch when necessary for now. More just a personal thought on how I would've expected the response setting to work. I'll take a look at openapi-fetch though, thanks

[mrlubos]

Thanks for providing context! Please let me know your thoughts if you do try openapi-fetch out

[mrlubos]

Hey @olliejm, just closing out this thread. The new clients have been released a while ago and they support both throwing on error as well as returning it, the choice is yours.