You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Try ... Catch ... Finally

Camel supports the Java equivalent of try .. catch and finally directly in the DSL.
It aims to work like its Java sisters but with more power. Especially in Camel 2.0 where we gave this feature an overhaul.

In Camel we prefix the keywords with do to avoid having same keyword as Java. So we have:

  • doTry
  • doCatch
  • doFinally
  • end to end the block in Java DSL

Notice this document is based on how it works in Camel 2.0. In Camel 1.x this feature isn't as powerful and it uses a slight different keyword names.

About doCatch and its power over Java

The doCatch in Camel is empowered over its Java sister. First of all you can define multiple exceptions to catch in a single block. And secondly you can attach a onWhen predicate to signal if the catch should trigger or not at runtime.

To simulate rehrowing an exception from a doCatch you should use the handled predicate. If its evaluated to false Camel will reattach the exception on the Exchange.

And just like Java the order in which you have multiple doCatch blocks matter. Camel will iterate from the top going down and use the first doCatch that matches the exception and if the onWhen predicate matches as well (if any provided). This is the same behavior as the Exception Clause.

Using try .. catch .. finally in Java DSL

In the route below we have all keywords in action. As the code is based on a unit test we route using Mock.

Error formatting macro: snippet: java.lang.NullPointerException

And in the route below we want to indicate if an IOException occured we want to route it elsewhere and at the same time keep the exception so the original caller is notified about this exception. To do this we need to not rethrow the exception and this is why we use handled and set it to false to indicate, no we did not handle it so please keep the exception.
The 2nd exception block can be omitted but as the code is based on an unit test we want to test the behavior non IOException as well.

Error formatting macro: snippet: java.lang.NullPointerException

And finally we have an example of the onWhen predicate in action. We can attach it to a doCatch block and at runtime determine if the block should be triggered or not.
In our case we only want to trigger if the caused exception message contains the damn word.

Error formatting macro: snippet: java.lang.NullPointerException
  • No labels