-
Notifications
You must be signed in to change notification settings - Fork 38.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nested Exception's message should not include the messages from causal chain #25162
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Milestone
Comments
spring-projects-issues
added
the
status: waiting-for-triage
An issue we've not yet triaged or decided on
label
May 29, 2020
jhoeller
added
for: team-attention
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
labels
May 29, 2020
jhoeller
removed
the
status: waiting-for-triage
An issue we've not yet triaged or decided on
label
Sep 25, 2020
jhoeller
added a commit
that referenced
this issue
Jun 14, 2022
artembilan
added a commit
to spring-projects/spring-integration
that referenced
this issue
Jun 28, 2022
* Upgrade Spring dependencies to the latest SNAPSHOTs * Fix tests to verify against stack traces: the message of the `NestedRuntimeException` does not include the nested exception information. Related to spring-projects/spring-framework#25162 * Fix `JdbcMessageStore` and `DefaultLockRepository` to rely on the `DataIntegrityViolationException` instead of only its `DuplicateKeyException` extension. This is the current behavior of the SQL errors translation * Disable `WebFluxDslTests.testValidation()` - doesn't subscribe to the reply somehow... * Refine `SimplePool.PoolSemaphore.reducePermits()`
fmbenhassine
pushed a commit
to spring-projects/spring-batch
that referenced
this issue
Jul 15, 2022
These tests started failing after an upstream change in Spring Framework [1]. [1]: spring-projects/spring-framework#25162
garyrussell
added a commit
to garyrussell/spring-kafka
that referenced
this issue
May 2, 2023
Resolves spring-projects#2671 With Spring Framework 6, `NestedRuntimeException.getMessage()` no longer includes the messages for nested exceptions via the cause chain. See spring-projects/spring-framework#25162 This means that the DLQ exception message header always contains the same `Failed listener` message. Find the root cause exception of the message and include its message in the header. Ignore any nested `TimestampedException` and `LEFE` between the top `LEFE` and the root cause; these will still appear in the stack trace.
garyrussell
added a commit
to garyrussell/spring-kafka
that referenced
this issue
May 2, 2023
Resolves spring-projects#2671 With Spring Framework 6, `NestedRuntimeException.getMessage()` no longer includes the messages for nested exceptions via the cause chain. See spring-projects/spring-framework#25162 This means that the DLQ exception message header always contains the same `Failed listener` message. Find the root cause exception of the message and include its message in the header. Ignore any nested `TimestampedException` and `LEFE` between the top `LEFE` and the root cause; these will still appear in the stack trace.
garyrussell
added a commit
to garyrussell/spring-kafka
that referenced
this issue
May 2, 2023
Resolves spring-projects#2671 With Spring Framework 6, `NestedRuntimeException.getMessage()` no longer includes the messages for nested exceptions via the cause chain. See spring-projects/spring-framework#25162 This means that the DLQ exception message header always contains the same `Failed listener` message. Find the root cause exception and include its message in the header. Ignore any nested `TimestampedException` and `LEFE` between the top `LEFE` and the root cause; these will still appear in the stack trace.
artembilan
pushed a commit
to spring-projects/spring-kafka
that referenced
this issue
May 2, 2023
Resolves #2671 With Spring Framework 6, `NestedRuntimeException.getMessage()` no longer includes the messages for nested exceptions via the cause chain. See spring-projects/spring-framework#25162 This means that the DLQ exception message header always contains the same `Failed listener` message. Find the root cause exception and include its message in the header. Ignore any nested `TimestampedException` and `LEFE` between the top `LEFE` and the root cause; these will still appear in the stack trace.
This was referenced Jul 13, 2023
harawata
added a commit
to harawata/spring
that referenced
this issue
Nov 23, 2023
Since Spring 6, org.springframework.core.NestedRuntimeException no longer include the message of the wrapped exception. spring-projects/spring-framework#25162 Should fix mybatisgh-887
harawata
added a commit
to harawata/spring
that referenced
this issue
Nov 23, 2023
Since Spring 6, `org.springframework.core.NestedRuntimeException` no longer includes the message of the wrapped exception. spring-projects/spring-framework#25162 Should fix mybatisgh-887
harawata
added a commit
to harawata/spring
that referenced
this issue
Nov 23, 2023
Since Spring 6, `org.springframework.core.NestedRuntimeException` no longer includes the message of the wrapped exception. spring-projects/spring-framework#25162 Should fix mybatisgh-887
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Change NestedRuntimeException, NestedCheckedException, etc so that the exception's
getMessage()
does not include the nested exception information.NestedRuntimeException was first introduced all the way back in spring 1.0 as compatibility for code still running in Java 1.3 or older version, which did not have exception chaining feature. To easily make the chained exception messages visible to the user on such old Java versions,
getMessage()
recursively included the messages.We are long past Java 1.3. Nowadays, the nested message information is extremely, unnecessarily verbose and repetitive.
Look at an example exception from a toy application.
And then look at the same exception without nested messages.
In typical large applications, the problem is exacerbated because the exception messages/stacktraces can span many many console pages. In most cases, we must locate the root exception anyways to make sense of it all because both the root exception message and the root stacktrace are needed to accurately diagnose the problem. The nested messages only impede the diagnostics.
Please remove nested exception messages.
The text was updated successfully, but these errors were encountered: