[REQ][C++][Pistache] Reconsider default error handling in generated code.

[JulianGmp]

Is your feature request related to a problem? Please describe.

In 8f56395 (PR #9251), I myself have introduced a more advanced error handling for the pistache server.

In the handleParsingException function and the handleOperationException function an unhandled exception will be matched to a pair with an http return code and an error message that will be sent to the client.
These functions can be overriden by the API impl if custom behaviour is necessary, but the default implementation (see code snippet below) will send out the what() message of any unhandled exception.

std::pair<Pistache::Http::Code, std::string> {{classname}}::handleParsingException(const std::exception& ex) const noexcept
{
    try {
        throw;
    } catch (nlohmann::detail::exception &e) {
        return std::make_pair(Pistache::Http::Code::Bad_Request, e.what());
    } catch ({{helpersNamespace}}::ValidationException &e) {
        return std::make_pair(Pistache::Http::Code::Bad_Request, e.what());
    } catch (std::exception &e) {
        return std::make_pair(Pistache::Http::Code::Internal_Server_Error, e.what())
    }
}
std::pair<Pistache::Http::Code, std::string> {{classname}}::handleOperationException(const std::exception& ex) const noexcept
{
    return std::make_pair(Pistache::Http::Code::Internal_Server_Error, ex.what());
}

For the use case I have, this solution is perfect, but I did not consider the consequences for other use cases.
Returning the error message for any unhandled exception, might leak sensitive information to the client, which could be damaging for publicly available APIs.

Describe the solution you'd like

I believe the decision I made should be reconsidered, and the default behaviour of the generated code should try to limit the information sent to the client.
The handleParsingException should only catch exceptions inside generated code, so it should be fairly controlled.
But I belive that only the json exception and ValidationException can be left the same, as json deserialization and validation exceptions apply to the data the client has sent to the server.

Describe alternatives you've considered

None - I merely want to start a discussion here.
I'm also tagging @muttleyxd and @etherealjoy as you two are part of the C++ technical committee.

Additional context

None

[etherealjoy]

For the use case I have, this solution is perfect, but I did not consider the consequences for other use cases.
Returning the error message for any unhandled exception, might leak sensitive information to the client, which could be damaging for publicly available APIs.

Is this really an issue, because you are basically linking to the lib and you can intercept everything. Since this is native code I mean.

You could try to throw generic exceptions for the server to handle but that would make the server to respond back with very generic error response preventing client from detecting what went wrong.

[JulianGmp]

that would make the server to respond back with very generic error response preventing client from detecting what went wrong.

I think that behaviour would be better suited for APIs that are publicly available on the internet, at least in my opinion.

I'm not sure if there is a general decision for this regarding all openapi generators.