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.

Comment From: philwebb

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.

Comment From: f-cramer

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.

Comment From: philwebb

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.