Common root cause introspection algorithm in NestedExceptionUtils [SPR-15510]

[spring-projects-issues]

Juergen Hoeller opened SPR-15510 and commented

AbstractSockJsSession currently uses a dummy NestedCheckedException just for access to root cause introspection. Let's extract that algorithm to NestedExceptionUtils and make it applicable to any Throwable directly.

We have the same need in HttpWebHandlerAdapter, so it's particularly important in 5.0 but also worth backporting the AbstractSockJsSession part to 4.3.9.

---

Affects: 4.3.8

Issue Links:

• Improve 500 error handling and reporting in WebFlux [SPR-15506] #20065 Improve 500 error handling and reporting in WebFlux

Referenced from: commits 9d8e9cf, 2d1b551

[spring-projects-issues]

Andrei Ivanov commented

I'm sure it's documented somewhere, but what's the point of the nested exception classes?
Are they some old relics or they really provide an improvement?

[spring-projects-issues]

Juergen Hoeller commented

They are to some degree legacy from the JDK 1.3 days... but also provide consistent exception message concatenation and a few convenient cause introspection methods (getRootCause, getMostSpecificCause, contains). It doesn't hurt for Spring's own exceptions to keep extending from those base classes even in Spring 5.

[spring-projects-issues]

Andrei Ivanov commented

Got it... I've noticed them when experimenting with spring-retry in a project without any Spring dependencies and I tried to exclude spring-core from the transitive deps it was pulling, just to get an exception about missing the nested exception classes :(