Currently if an exception such as MissingServletRequestParameterException
is thrown no stack-trace is logged. It would be useful to provide an option to add them.
Something like this in EnableWebMvcConfiguration
:
@Override
protected void configureHandlerExceptionResolvers(
List<HandlerExceptionResolver> exceptionResolvers) {
addDefaultHandlerExceptionResolvers(exceptionResolvers);
for (HandlerExceptionResolver resolver : exceptionResolvers) {
if (resolver instanceof DefaultHandlerExceptionResolver) {
((DefaultHandlerExceptionResolver) resolver)
.setWarnLogCategory(DefaultHandlerExceptionResolver.class
.getName());
}
}
}
I'm not sure if this should be on or off by default.
@wilkinsona @dsyer Any thoughts about this? Trying to debug #2162 highlighted the problem. Not sure if we should enable by default because the logs could get pretty full just by people posting incomplete data.
Tricky one. On the one hand, it could be used as a form of DoS attack if you managed to flood the logs with exception messages. On the other hand, it'd make problem diagnosis easier.
I could be convinced either way but perhaps we should err toward secure by default and default to off?
Moving to 1.3. Could be another good candidate to enable during development but not in production.
I'm not familiar enough with the internals of the MVC chain post-controller to say whether mine is a duplicate, but they're semantically related. This one seems to be dealing with resolving controller arguments, and mine is about exceptions thrown after the controller has returned an argument during JSON/XML serialization.
@philwebb I gave that a try, you can find a proposal (see https://github.com/snicoll/spring-boot/commit/745671a99a4ec48e3aca055480bc74b0ef057fbe)
Let's assume I have added a @ResponseStatus
annotation on a custom exception, here's what I get for a _single_ call to the service that throws that exception:
2016-05-24 13:28:05.641 WARN 97219 --- [nio-8080-exec-1] .m.m.a.ExceptionHandlerExceptionResolver : Handler execution resulted in exception: com.example.DemoApplication$MyException
2016-05-24 13:28:05.643 WARN 97219 --- [nio-8080-exec-1] .w.s.m.a.ResponseStatusExceptionResolver : Handler execution resulted in exception: com.example.DemoApplication$MyException
Your proposal above does not work as MVC ships with 3 "default" resolvers and that default is the fallback. Spring MVC logs the exception even if the handler does not ultimately resolve the model (that's what happens with ExceptionHandlerExceptionResolver
).
Long story short:
DefaultHandlerExceptionResolver
looks incomplete to me: there are two other implementations _before_ this one that have a chance to resolve the exceptionThoughts?
Tested in 1.3.5.RELEASE
I was forced to workaround like this:
@Slf4j //lombok
@ResponseStatus(HttpStatus.BAD_REQUEST)
public class MyCustomException extends RuntimeException {
public MyCustomException(String msg) {
super(msg);
log.warn(msg, this);
}
}
Otherwise, no way to see my custom exception in the log.
SPR-14392 has been fixed.
You should now get a single WARN log when the exception is actually resolved, like this:
[.m.m.a.ExceptionHandlerExceptionResolver] - Resolved exception caused by Handler execution: java.lang.IllegalStateException
@snicoll I think you can now merge your proposal.
Exception has been correctly processed by ExceptionHandler. What's the point to log it? What's the point to log it at WARN level? What's the point to enable it by default?
When I have ControllerAdvice and have method anotated with ExceptionHandler and I'm doing redirect ExceptionHandlerExceptionResolver logs with WARN level.
Why?
I already handled custom exception and logged it
ExceptionHandlerExceptionResolver
is part of Spring Framework. If you have a question about it, please ask on Stack Overflow. If you have a suggestion for an improvement, please open a JIRA ticket.
@TorosyanV I have same issue and having to fix by setting log level to ERROR. I wonder if you found a better way.
org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver: ERROR
Most helpful comment
Exception has been correctly processed by ExceptionHandler. What's the point to log it? What's the point to log it at WARN level? What's the point to enable it by default?