Skip to content
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

Message not included in ErrorAttributes for non-RuntimeExceptions #40341

Closed
f-cramer opened this issue Apr 12, 2024 · 3 comments
Closed

Message not included in ErrorAttributes for non-RuntimeExceptions #40341

f-cramer opened this issue Apr 12, 2024 · 3 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@f-cramer
Copy link

When a non-RuntimeException (e.g. any Throwable that does not inherit from RuntimeException) is thrown in a method called via ReflectionUtils#invokeMethod(java.lang.reflect.Method, java.lang.Object) it is wrapped in a java.lang.reflect.UndeclaredThrowableException without propagating its message.
This means that depending on whether or not the exception being thrown is a RuntimeException the ErrorAttributes that are create when this method is called in a Controller look slightly different:
For the RuntimeException its message property is equal to error.getMessage, for other Exceptions the fallback "No message available" is used (because of the wrapping in invokeMethod). In both cases the response status is not dependent on the type of Exception. It is equal to 500 or the value of the exceptions @ResponseStatus annotation.
This behaviour was observed in the @EventHandler support of spring-data-rest where ReflectionUtils#invokeMethod is called in AnnotatedEventHandlerInvoker#onApplicationEvent

You can find an example at https://github.com/f-cramer/spring-error-attributes.
The application has two endpoints http://localhost:8080/exception and http://localhost:8080/runtimeException, that throw a subclass of Exception and a subclass of RuntimeException respectively.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 12, 2024
@philwebb philwebb added the for: team-meeting An issue we'd like to discuss as a team to make progress label Apr 13, 2024
@philwebb
Copy link
Member

We discussed this today as a team and we're not keen to unwrap UndeclaredThrowableException ourselves. The main reason is that UndeclaredThrowableException does have a constructor that accepts a message so we can't be sure that a user hasn't crafted a specific instance with a message that they want to use.

To solve your specific problem we recommend subclassing DefaultErrorAttributes and overriding the getMessage method. This should allow you to find the message that you want to display. If you register your own class as a bean, our auto-configuration will back off.

@philwebb philwebb closed this as not planned Won't fix, can't repro, duplicate, stale Apr 15, 2024
@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged for: team-meeting An issue we'd like to discuss as a team to make progress labels Apr 15, 2024
@f-cramer
Copy link
Author

Does this rejection also include a rejection to change ReflectionUtils#invokeMethod(java.lang.reflect.Method, java.lang.Object) in Spring Framework, or should I create another issue there? Sorry, I don't now if the teams for Boot and Framework are the same or not.

@philwebb
Copy link
Member

Sorry @f-cramer, I missed that part. The ReflectionUtils class is part of Spring Framework so you can make a request at https://github.com/spring-projects/spring-framework/issues/new.

I suspect that it might be declined since we don't often propagate messages when wrapping exceptions, but it can't hurt to ask.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

3 participants