Page History

...

<onException>
   <exception>com.mycompany.MyBusinessException</exception>
   <exception>com.mycompany.MyOtherBusinessException</exception>
   <redeliveryPolicy maximumRedeliveries="2"/>
   <to uri="activemq:businessFailed"/>
</onException>

Using a processor as failure handler

We want to handle certain exceptions specially so we add a onException clause for that exception.

{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionProcessorInspectCausedExceptionTest.java}

So what happens is that whenever a MyFunctionalException is thrown it is being routed to our processor MyFunctionFailureHandler. So you can say that the exchange is diverted when a MyFunctionalException is thrown during processing. It's important to distinct this as perfect valid. The default redelivery policy from the Dead Letter Channel will not kick in, so our processor receives the Exchange directly, without any redeliver attempted. In our processor we need to determine what to do. Camel regards the Exchange as failure handled. So our processor is the end of the route. So lets look the code for our processor.

{snippet:id=e2|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionProcessorInspectCausedExceptionTest.java}

Notice how we get the caused by exception using a property on the Exchange. This is where Camel stores any caught exception during processing. So you can fetch this property and check what the exception message and do what you want. In the code above we just route it to a mock endpoint using a producer template from Exchange.

Marking exceptions as being handled

...