Expert Spring MVC and Web Flow

Listing 5-24 contains sample code that programmatically illustrates what view name is

resolved when an ExceptionChildexception is thrown.

Listing 5-24.Test Case

ModelAndView mav = resolver.resolveException(req, res, handler,

new ExceptionChild());

assertEquals("exceptionPage", mav.getViewName()); // true!

Notice how, in Listing 5-24, the SimpleMappingExceptionResolverreturned the view name

exceptionPage, even though there was a rule to map an ExceptionChildexception.

Rule Number Two

The second rule comes in two parts. Exception mappings are aware of their superclasses, so

a mapping for a class will resolve to that class and all of its subclasses. Given the exception

classes from the previous example, the code in Listing 5-25 illustrates this rule.

Listing 5-25.Exception Resolver Configuration for ExceptionParent

<?xml version="1.0"?>

<!DOCTYPE beans PUBLIC

"-//SPRING//DTD BEAN//EN"

"http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="exceptionMapping"

class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">

<property name="exceptionMappings">

<props>

<prop key="ExceptionParent">parentPage</prop>

</props>

</property>

</bean>

</beans>

Listing 5-26 simply shows that even those an ExceptionChildwas thrown, the mapping

for ExceptionParentresolves.

Listing 5-26.Test Case

ModelAndView mav = resolver.resolveException(req, res, handler,

new ExceptionChild()); // throwing child subclass

assertEquals("parentPage", mav.getViewName()); // true!

Now, here is the second part of the rule. If you specify both the parent exception and the

child exception, then the child exception will resolve. So, even though the resolving logic will

scan the exception class hierarchy for a match, it will prefer a match lower in the tree.

98 CHAPTER 5 ■THE PROCESSING PIPELINE