Fix SQL logging and add catch-all exception handler (continuation w #11988)

[nishantharkut]

Fix #11987

Describe changes proposed in this pull request:

• Replace ex.printStackTrace() in handleBadSqlGrammar with LOG.error("SQL grammar exception", ex) so SQL exceptions route through the SLF4J/Logback pipeline instead of writing directly to System.err
• Add @ExceptionHandler(Exception.class) catch-all so all unhandled exceptions return a structured JSON ErrorResponse (HTTP 500) instead of leaking raw stack traces to API consumers
• Add GlobalExceptionHandlerTests covering both changed methods

Note: the parameter type mismatch in handleCacheOperationException is already addressed by #11988 and is excluded from this PR intentionally.

Checks

• The commit log is comprehensible. It follows 7 rules of great commit messages. We can fix this during merge by using a squash+merge if necessary
• Has tests or has a separate issue that describes the types of test that should be created. If no test is included it should explicitly be mentioned in the PR why there is no test.
• Is this PR adding logic based on one or more clinical attributes? If yes, please make sure validation for this attribute is also present in the data validation / data loading layers (in backend repo) and documented in File-Formats Clinical data section!
• Make sure your PR has one of the labels defined in https://github.com/cBioPortal/cbioportal/blob/master/.github/release-drafter.yml

Any screenshots or GIFs?

N/A — backend-only change, no visual output.

Notify reviewers

handleBadSqlGrammar was introduced by @LukeSikina, cache eviction handling by @pvannierop, and the most recent change to this file was by @gblaih.

[Copilot]

Pull request overview

This PR updates the REST GlobalExceptionHandler to route SQL grammar exceptions through SLF4J logging and introduces a catch-all exception handler intended to ensure unhandled errors return a structured JSON ErrorResponse (500), alongside new unit tests.

Changes:

• Replace printStackTrace() in handleBadSqlGrammar with LOG.error(...).
• Add @ExceptionHandler(Exception.class) to return a generic 500 ErrorResponse for otherwise-unhandled exceptions.
• Add GlobalExceptionHandlerTests for handleBadSqlGrammar and the new catch-all handler.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/main/java/org/cbioportal/application/rest/error/GlobalExceptionHandler.java	Adds SLF4J logger usage, improves SQL exception logging, and adds a catch-all exception handler.
src/test/java/org/cbioportal/application/rest/error/GlobalExceptionHandlerTests.java	Adds unit tests covering the updated SQL handler and the new catch-all handler.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

@ExceptionHandler(Exception.class) will also intercept Spring MVC framework exceptions (e.g., HttpRequestMethodNotSupportedException, HttpMediaTypeNotSupportedException, etc.) that would otherwise be translated to correct 4xx/405 responses by Spring’s default resolvers. With this catch-all in place, those cases may start returning a generic 500 ErrorResponse instead. Consider narrowing the handler to RuntimeException (to avoid overriding framework 4xx handling) and/or adding explicit handlers for common Spring MVC exceptions with appropriate HTTP statuses, or extending ResponseEntityExceptionHandler to preserve the default mappings while still returning JSON.

[nishantharkut]

@inodb @dippindots could you please add the bug label to this PR? The label-check CI will fail until a valid label from the release-drafter categories is applied. Thank you!

[nishantharkut]

Addressed Copilot's feedback on the catch-all handler.

@ExceptionHandler(Exception.class) on its own intercepts Spring MVC framework exceptions (HttpRequestMethodNotSupportedException → 405, HttpMediaTypeNotSupportedException → 415, etc.) before they can be translated to their correct 4xx responses — turning them all into 500s instead.

Fixed by extending ResponseEntityExceptionHandler. The parent class registers specific handlers for all those framework exception types in the class hierarchy. Spring's ExceptionHandlerMethodResolver picks the most specific type match, so the parent's handlers continue to fire for Spring MVC framework exceptions, while the Exception.class catch-all only fires for genuinely unhandled application exceptions.

This also resolves the TODO that was already in the file (// - consider extending extends ResponseEntityExceptionHandler).