You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
When a non-
RuntimeException
(e.g. anyThrowable
that does not inherit fromRuntimeException
) is thrown in a method called viaReflectionUtils#invokeMethod(java.lang.reflect.Method, java.lang.Object)
it is wrapped in ajava.lang.reflect.UndeclaredThrowableException
without propagating its message.This means that depending on whether or not the exception being thrown is a
RuntimeException
theErrorAttributes
that are create when this method is called in a Controller look slightly different:For the
RuntimeException
its message property is equal toerror.getMessage
, for otherException
s the fallback"No message available"
is used (because of the wrapping ininvokeMethod
). In both cases the response status is not dependent on the type ofException
. It is equal to 500 or the value of the exceptions@ResponseStatus
annotation.This behaviour was observed in the
@EventHandler
support ofspring-data-rest
whereReflectionUtils#invokeMethod
is called inAnnotatedEventHandlerInvoker#onApplicationEvent
You can find an example at https://github.com/f-cramer/spring-error-attributes.
The application has two endpoints
http://localhost:8080/exception
andhttp://localhost:8080/runtimeException
, that throw a subclass ofException
and a subclass ofRuntimeException
respectively.The text was updated successfully, but these errors were encountered: