usage question re: afterCompletion from handlerInterceptor

[zlendon]

Are people using afterCompletion to handle errors that might occur when actually rendering their views? Any other interesting usage in this method? I've not really leveraged this method in the past; I can imagine how it could be beneficial, but wanted to see how others might have applied it to give me additional ideas...

[irbouho]

afterCompletion is garantee to execute even if the controller / view throws an exception. This method is an excellent candidate to implement cleanup code.
For a use case, take a look at OpenSessionInViewInterceptor, OpenEntityManagerInViewInterceptor...

HTH

[brucebaron]

afterCompletion is garantee to execute even if the controller / view throws an exception. This method is an excellent candidate to implement cleanup code.
For a use case, take a look at OpenSessionInViewInterceptor, OpenEntityManagerInViewInterceptor...

HTH

Another usage question: Is it the case that the exception argument of afterCompletion is non-null for unresolved exceptions only? That is, if the controller throws an exception that is mapped to an ExceptionResolver, this exception will not be passed into afterCompletion.

If this is the expected behavior, it would be helpful to note this in the JavaDoc of this method. I'm writing an interceptor that populates runtime stats in an MBean. It took me awhile to realize that the exception I'm expecting to receive isn't passed in because the exception was already resolved.

[AuPanner]

Another usage question: Is it the case that the exception argument of afterCompletion is non-null for unresolved exceptions only? That is, if the controller throws an exception that is mapped to an ExceptionResolver, this exception will not be passed into afterCompletion.

Ancient question, but following up for posterity. It is even more specific than that. As of 3.1.0, the exception parameter of afterCompletion is only defined if an exception is thrown during the render() call or if the ExceptionHandler (or ExceptionResolver) itself throws an exception. So if you have nice code that catches the exception and yields a reasonable view, you'll never see an exception passed to afterCompletion.

[plovec]

Ancient question, but following up for posterity. It is even more specific than that. As of 3.1.0, the exception parameter of afterCompletion is only defined if an exception is thrown during the render() call or if the ExceptionHandler (or ExceptionResolver) itself throws an exception. So if you have nice code that catches the exception and yields a reasonable view, you'll never see an exception passed to afterCompletion.

Is there any way to pass that exception to afterCompletion()? I have precisely the situation you described (legacy code) where ExceptionResolver handles exception, and afterCompletion() is called afterwards. The problem is, afterCompletion() relies on that passed exception to complete the transaction. It is legacy code and while I understand possibly bad design, I'd just like to fix it as simply as possible and not redesign everything. Thanks in advance!