springframework-developer

Re: [Springframework-developer] HandlerInterceptor is a misleadingname

[Juergen H. <ju...@in...>]

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
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Matt Sgarlata
Sent: Monday, July 24, 2006 4:00 PM
To: spr...@li...
Subject: Re: [Springframework-developer] HandlerInterceptor is a
misleadingname

Yeah, the response may already be screwed up, but there's still the
potential to log the error or email the sys admin.  I implemented this
functionality in my app very easily as follows

public class ViewExceptionInterceptor extends HandlerInterceptorAdapter {

   private static final Logger logger =
Logger.getLogger(ViewExceptionInterceptor.class);

   public void afterCompletion(HttpServletRequest request,
HttpServletResponse response, Object handler, Exception ex) throws Exception
{
     if (ex != null) {
       logger.error("Error while rendering view", ex);
     }

     super.afterCompletion(request, response, handler, ex);
   }

}


I just posted this on dev because I thought if there's ever a time to
reconsider the name for HandlerInterceptor it's now, since AFAIK the
interface is new in Spring 2, and Spring 2 hasn't technically been released
yet.  RequestInterceptor or WebInterceptor might be a better name.

Matt

Juergen Hoeller wrote:
> Point taken, Matt.
> 
> I'm not opposed to adding callback support for view exceptions. 
> However, we can't get rid of the issue that a view exception will 
> usually lead into a situation where we can't render a proper error 
> page anymore, since we already sent part of the original response to the
client...
> 
> Juergen
>  
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Matt Sgarlata
> Sent: Friday, July 21, 2006 9:36 PM
> To: spr...@li...
> Subject: [Springframework-developer] HandlerInterceptor is a 
> misleading name
> 
> HandlerInterceptors actually intercept both handlers and views, 
> whereas HandlerExceptionResolvers only resolve exceptions for 
> handlers.  Just wanted to point this out...
> 
> Matt
> 
> 
> ----------------------------------------------------------------------
> --- Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to share 
> your opinions on IT & business topics through brief surveys -- and 
> earn cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV
> DEV _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> ----------------------------------------------------------------------
> --- Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to share 
> your opinions on IT & business topics through brief surveys -- and 
> earn cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV
> DEV


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

Re: [Springframework-developer] HandlerInterceptor is a misleadingname

[Colin Y. <col...@gm...>]

>
> 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.


The ServletResponse doesn't support using *both* getWriter or
getOutputStream, it is one or the other.  As you said, if the browser has
started receiving, and expecting binary data it would be non-sensical to
send html as the content type would all be wrong.