swagger-api / swagger-api/swagger-codegen
C# Typed ApiException (or deserialization of ApiException.Content)
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 17.8k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
I'm making use of BadRequest in WebAPI to respond with validation errors. It works great in JavaScript, but encountering it in C# with swagger-codegen output, those responses get translated into ApiException which only provides a string (generally containing JSON).
[I saw that this was only added last summer](: https://github.com/swagger-api/swagger-codegen/pull/825/files). Is the intention that the consumer parse the JSON to read the error messages? I've written some code to make more use of the dynamic, instead of always just stuffing a string into it:
if (localVarStatusCode >= 400)
{
dynamic content;
try { content = JToken.Parse(localVarResponse.Content); }
catch { content = localVarResponse.Content; }
throw new ApiException(localVarStatusCode, "Error calling ...: " + localVarResponse.Content, content);
}
Although, even more ideally an ApiException<T> could be thrown using the type specified for a 400 error (Bad Request) by the spec.
Furthermore, is it possible for me to take advantage of this approach now without changing the generated files each time (e.g. changing the template)? My change obviously relies on the Newtonsoft Json library, which may not be something you guys want a dependency on?
TIA!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the generated C# ApiException behavior described here and review the referenced pull request 825, then inspect the C# templates that produce generated files. Determine whether error content should be deserialized or exposed through a typed ApiException without requiring manual edits or an unwanted dependency. Done means the project has an agreed implementation path and corresponding template behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100