Re: [Springframework-developer] HandlerInterceptor is a misleadingname

[Matt S. <mat...@sp...>]

I did some testing with a controller that wrote directly to the response 
(using response.getWriter()) and then threw an exception.  This caused 
my global HandlerExceptionResolver to kick in, and Spring happily 
continued and appended my error view to the end of the response.  That 
behavior is probably just fine the way it is now.

If binary data was written directly to the response and then an 
exception thrown, I'm not sure what exactly would happen, but if you're 
streaming a dynamic image or something like that I'm sure you can safely 
assume whether Spring blows up or not that you'll get a bogus response 
from the server.

I would love to see a new 
HandlerExceptionResolver.resolveViewException(request, response, 
handler, exception) method added.

I think there should also be a 
HandlerExceptionResolver.postProcessException method that allows for the 
implementation of logic that is common to both controller and view 
exception handling.

Matt

Juergen Hoeller wrote:
> HandlerInterceptor has actually been around for years, so I'm afraid it's
> not as easy to rename. I'm not too bothered with the present name either,
> though.
> 
> I'm still open to adding a view exception callback to
> HandlerExceptionResolver. You do have a point that if we have
> afterCompletion in HandlerInterceptor, we can just as well add a
> resolveViewException method (or the like) to HandlerExceptionResolver.
> 
> One further issue to consider here is that a handler is actually allowed to
> write the view to the response directly and return null as ModelAndView. The
> present HandlerExceptionResolver can't forward to an error view here either,
> similar to the situation of an exception during JSP rendering.
> 
> Juergen