Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: CAMEL-976

...

Code Block
onException(MyBusinessException.class, MyOtherBusinessException.class).
  to("activemq:businessFailed");

But the most important new feature is support for marking exceptions as being handled.

Marking exceptions as being handled

Available as of Camel 1.5

Using onException to handle known exceptions is a very powerful feature in Camel. However prior to Camel 1.5 you could not mark the exception as being handled, so the caller would still receive the caused exception as a response. In Camel 1.5 you can now change this behaviour with the new handle DSL. The handle is a Predicate that is overloaded to accept three types of parameters:

  • Boolean
  • Predicate
  • Expression that will be evaluates as a Predicate using this ruleset: If the expressions returns a Boolean its used directly. For any other response its regarded as true if the response is not null.

For instance to mark all ValidationException as being handled we can do this:

Code Block

  onException(ValidationException).handled(true);

Example using handled

In this route below we want to do special handling of all OrderFailedException as we want to return a customized response to the caller. First we setup our routing as:

Wiki Markup
{snippet:id=e1|lang=java|url=activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelHandledExampleTest.java}

Then we have our service beans that is just plain POJO demonstrating how you can use Bean Integration in Camel to avoid being tied to the Camel API:

Wiki Markup
{snippet:id=e2|lang=java|url=activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelHandledExampleTest.java}

And finally the exception that is being thrown is just a regular exception:

Wiki Markup
{snippet:id=e3|lang=java|url=activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelHandledExampleTest.java}

So what happens? If we sent an order that is being processed OK then the caller will receive an Exchange containing Order OK and payload and the order id 123 as a header.
If the order could not be processed and thus an OrderFailedException was thrown the caller will not receive this exception (as in Camel 1.4) but our customized response that we have fabricated in the orderFailed method in our OrderService. So the caller receives an Exchange with the payload Order ERROR and a header with orderid = failed.

Overloading the RedeliveryPolicy

...

However if you want to customize any methods on the RedeliveryPolicy object, you can do this via the fluent API...

Code Block
exceptiononException(MyException.class).
  maximumRedeliveries(2);

...