From 09bd716d48c27ed9ae2f0892ad0dcd9811d1ccb6 Mon Sep 17 00:00:00 2001 From: gayathrisairam <168187165+gayathrisairam@users.noreply.github.com> Date: Wed, 18 Sep 2024 08:49:34 +0100 Subject: [PATCH] Update Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0011.md Co-authored-by: Honza Dvorsky --- .../Documentation.docc/Proposals/SOAR-0011.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0011.md b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0011.md index b8915b04..0180cd7a 100644 --- a/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0011.md +++ b/Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0011.md @@ -18,7 +18,7 @@ introduces a way for users to map errors thrown by their handlers to specific HT ### Motivation - When implementing a server with Swift OpenAPI Generator, users implement a type that conforms to a generated protocol, providing one method for each API operation defined in the OpenAPI document. At runtime, if this function throws, the runtime library transforms this into a 500 HTTP response (Internal Error). + When implementing a server with Swift OpenAPI Generator, users implement a type that conforms to a generated protocol, providing one method for each API operation defined in the OpenAPI document. At runtime, if this function throws, it's up to the server transport to transform it into an HTTP response status code – for example, some transport use `500 Internal Error`. Instead, server developers may want to map errors thrown by the application to a more specific HTTP response. Currently, this can be achieved by checking for each error type in each handler's catch block, converting it to an