...
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.
...
When using doTry .. doCatch .. doFinally
then the regular Camel Error Handler does not apply. That means any onException
or the likes does not trigger. The reason is that doTry .. doCatch .. doFinally
is in fact its own error handler and that it aims to mimic and work like how try/catch/finally works in Java.
...
doTry
around a Content Based Router not supported
...
...
from("direct:dotry").setExchangePattern(ExchangePattern.InOut)
.doTry()
.to("https://localhost:8080/rest/order/123")
.choice()
.when().simple("${header.CamelHttpResponseCode} == '200'")
.convertBodyTo(String.class)
// DO SOMETHING
.endChoice()
.doCatch(Exception.class) // NOT SUPPORTED !!
.log(">> Exception")
.endDoTry();
The ChoiceDefinition class which is part of the DSL language of Apache Camel to implement the Content Based Router EIP Pattern doesn’t extends the OutputDefinition, which means that you cannot define the doCatch after the ChoiceDefinition as presented with the previous example. If you want to catch the exception inside of ChoiceDefinition, you can use error handler or use doTry…doCatch inside of when part.
About doCatch
and its power over Java
...
In the route below we have all keywords in action. As the code is based on a unit test we route using Mock.
...
...
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.
...
...
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.
...
Notice when using Java DSL we must use end()
to indicate where the try .. catch .. finally block ends. As the example above has a finally, then the end()
should be at the end of the finally block. If we are not using a finally, then the end()
should be at the end of the doCatch
to indicate the end there.
...
In the route below we have all keywords in action. As the code is based on a unit test we route using Mock.
...
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.
...
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.
...
...