You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if a user consumes an API which has multiple non-2xx return types, NSwag generates a generic SwaggerException<TResult> class and instantiates it for each documented return type.
The problem is that the user needs to browse the generated code in order to figure out which possible TResults he needs to catch. As best as I can tell, there is no way to discover than from the client's public interface.
Proposed solution 1
Add XML comments to the generated ExceptionClasses, listing the possible types returned by each call.
Pro: Much simpler to implement, could be as simple as adding a few lines to File.liquid
Con: No type safety. Also, since the client could be using either a single {controller}Exception class for all endpoints in the controller, or even by default a single SwaggerException class for the entire API, the XML comments would grow very unwieldy!
Proposed solution 2
Instead of generating a generic subclass of SwaggerException, generate specific subclasses for each return type. (I would make them nested classes as well, to help discoverability.)
Pro: Type safe, easier to use
Con: More complex to implement
The text was updated successfully, but these errors were encountered:
Issue:
Currently, if a user consumes an API which has multiple non-2xx return types, NSwag generates a generic
SwaggerException<TResult>
class and instantiates it for each documented return type.The problem is that the user needs to browse the generated code in order to figure out which possible
TResult
s he needs to catch. As best as I can tell, there is no way to discover than from the client's public interface.Proposed solution 1
Add XML comments to the generated
ExceptionClass
es, listing the possible types returned by each call.Pro: Much simpler to implement, could be as simple as adding a few lines to File.liquid
Con: No type safety. Also, since the client could be using either a single
{controller}Exception
class for all endpoints in the controller, or even by default a singleSwaggerException
class for the entire API, the XML comments would grow very unwieldy!Proposed solution 2
Instead of generating a generic subclass of SwaggerException, generate specific subclasses for each return type. (I would make them nested classes as well, to help discoverability.)
Pro: Type safe, easier to use
Con: More complex to implement
The text was updated successfully, but these errors were encountered: