Handling the case when not 2xx response is desired

[adamvandenhoven]

When Kiota encounters an "Error" of some sort it throws an exception. This is a reflection of what the HTTP RFC says (section 10.4 of HTTP 1.1 rfc is "Client Error 4xx") but it is not a reflection of what clients intend.

A case in point. You have a CRM type system with Dealers and Customers. In there you have /dealers/{dealerid}/customer/{customerId} which returns some representation of the relationship between dealers and customers. if there is a relationship, 200 -- here's what we know; if not, 404 -- doesn't exist.

Fine.

But in my app, I have a forking code path whether or not a dealer has a relationship. If none exists, you have to prompt the dealer to get the permission of the client ... whatever. Kiota throws the 404, this means that my logic has to be handled using exception handling, which is generally an anti-pattern. Moreover, some languages (Type/javascript javascript) do not handle exceptions well enough in this situation that you can easily distinguish between 404 ... do this next ... and 500 ... PANIC!!! ... you can obviously do it, but not as cleanly as having multiple typed catches.

One solution I can think of wrapping the kiota client's methods and return something Monadish (Result<DealerCustomerRelationship, ProblemDetails>) and keep all the exception handling neatly contained there.

But it occurs to me that there might be a better way.

[adamvandenhoven]

I should also mention that using a filtered search /dealers/{dealerid}/customers?id=customerId that returns something like { "data": []} when the relationship doesn't exist could also work, but you may not have that option.

[baywet]

Hi @adamvandenhoven
Thank you for using kiota and for reaching out.
I'm not sure what the question is at this point?

[adamvandenhoven]

First of all, how is that you're so consistently polite in these discussions? I don't think that's how the interwebs are supposed to work 😉

But I guess my question is "is exception catching really the best/only way to deal with the situation where a 404 is the right response?" I'm guessing that it is, but I figured I'd double check.

Also, what is thrown?

I have a couple APIs that I've inherited and I'm using Kiota to wire up some tests against the running services so that as my team eventually lifts the entire API into a new implementation, we can prove the new system does all the same things as the old system (warts and all). In there I have the following test:

  var getDealerBadly = () =>  companyClient.Companies["youcantseeme"].GetAsync();
  await getDealerBadly.Should().ThrowAsync<ProblemDetails>();

which fails with Expected a <Company.Models.ProblemDetails> to be thrown, but found <Microsoft.Kiota.Abstractions.ApiException>. Putting information for the end user about the nature of the error (mostly for 422 errors where these fields failed validation in these ways) should be helpful, but if I can't extract that info from the client, I'm not sure I'll continue to put effort into the shape of error responses.

[baywet]

how is that you're so consistently polite in these discussions?

🇨🇦🇨🇦🇨🇦🇨🇦

"is exception catching really the best/only way to deal with the situation where a 404 is the right response?

This is an opinionated decision we've made. In most languages dealing with an exception is more familiar to developers than monads or equivalent. And there's no way to tell a "good 400" from a "bad one" from the open API specification. So they should all be treated the same way.

which fails with Expected a <Company.Models.ProblemDetails> to be thrown, but found <Microsoft.Kiota.Abstractions.ApiException>

Assuming the description describes this problem detail, the client will throw a problem details instead of API exception. Which will also inherit from API exception so you retain access to the status code etc. Sharing your description here would help tell if anything could be changed to provide a better experience.

Let us know if you have any additional questions.

[adamvandenhoven]

The schema doc I'm using was originally incomplete (its not created by code) and apparently this was the one route that did't have a 404 defined, and I hadn't seen it.

Thx