Response with 500 on unhandled exceptions

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary: Updates the server’s generic exception handler to return 500 Internal Server Error instead of 405 Method Not Allowed when an unhandled exception occurs.
Why: Aligns the HTTP status code with the actual failure mode (unexpected server-side error) so clients can react appropriately.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[cubic-dev-ai]

2 issues found across 1 file

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/server/server.cc">

<violation number="1" location="src/server/server.cc:301">
P2: Now that this catch block handles genuine internal server errors (500), returning `error.what()` directly in the response risks leaking sensitive internal details (file paths, library error messages, configuration info) to clients. For 500 responses, consider using a generic error message in the response and logging the detailed exception message server-side only.</violation>

<violation number="2" location="src/server/server.cc:301">
P1: This catch block only handles `std::exception`-derived types. If `dispatch` is marked `noexcept`, any non-`std::exception` throw (e.g., an integer, string, or third-party exception type) will bypass this handler and invoke `std::terminate`, crashing the server instead of returning a 500. Add a `catch (...)` clause after this block to fully cover unhandled exceptions.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}