Spring Integration - Spring Enterprise Recipes: A Problem Solution Approach - page 327

((MessagingException) throwable).getFailedMessage();
if (failedMessage != null) {
// do something with the original message
}
} else {
// it's something that was thrown in the
// execution of code in some component you created
}
}
}

All errors thrown from Spring Integration components will be a subclass of MessagingException .
MessagingException carries a pointer to the original Message that caused an error, which you can dissect
for more context information. In the example, you're doing a nasty instanceof . Clearly, being able to
delegate to custom exception handlers based on the type of exception would be useful.

Routing to Custom Handlers Based on the Type of Exception
Sometimes more specific error handling is required. One way to discriminate by Exception type is to
use the org.springframework.integration.router.ErrorMessageExceptionTypeRouter . This router is
configured as a router component, which in turn listens to errorChannel . It then splinters off, using the
type of the exception as the predicate in determining which channel should get the results.

<?xml version="1.0" encoding="UTF-8"?>

<beans:beans xmlns:beans=" http://www.springframework.org/schema/beans"
…
>
<context:annotation-config/>
<channel id="customErrorChannelForMyCustomException"/>
<beans:bean id="myCustomErrorRouter"

➥
class="org.springframework.integration.router. ➥

ErrorMessageExceptionTypeRouter">
<beans:property name="exceptionTypeChannelMap">
<beans:map key-type="java.lang.Class">
<beans:entry
key="com.apress.springenterpriserecipes. ➥
springintegration.MyCustomException"
value-ref="customErrorChannelForMyCustomException" />
</beans:map>
</beans:property>
</beans:bean>
<router input-channel="errorChannel" ref="myCustomErrorRouter"/>
</beans:beans>

Building a Solution with Multiple Error channels
The preceding might work fine for simple cases, but often different integrations require different error-
handling approaches, which implies that sending all the errors to the same channel can eventually lead
to a large “switch”-laden class that's too complex to maintain. Instead, it's better to selectively route
error messages to the error channel most appropriate to each integration. This avoids centralizing
all error handling. One way to do that is to explicitly specify on what channel errors for a given
integration should go. The following example shows a component ( service-activator ) that upon