anchor.diff:  [[TryCatchFinally-Usingtry..catch..finallyinSpringDSL]]
   == Using try .. catch .. finally in Spring DSL
   
  -We show the three sample samples using Spring DSL instead.
  -
   In the route below we have all keywords in action. As the code is based
   on a unit test we route using xref:components::mock-component.adoc[Mock].
   
   https://github.com/apache/camel/tree/master/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/SpringTryProcessorMultipleExceptionTest.xml[SpringTryProcessorMultipleExceptionTest.xml]
  -
  -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.
  -
  -https://github.com/apache/camel/tree/master/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/SpringTryProcessorHandledTest.xml[SpringTryProcessorHandledTest.xml]
   
   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
  
positive.code: In the route below we have all keywords in action. As the code is based
  on a unit test we route using xref:components::mock-component.adoc[Mock].
  
  https://github.com/apache/camel/tree/master/camel-core/src/test/java/org/apache/camel/processor/TryProcessorMultipleExceptionTest.java[TryProcessorMultipleExceptionTest.java]
  
  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.
  
  https://github.com/apache/camel/tree/master/camel-core/src/test/java/org/apache/camel/processor/TryProcessorHandledTest.java[TryProcessorHandledTest.java]
  
  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
  
negative.code: 
  And second of all an important aspect over the regular Java counter
  parts is that Camel will check in the exception hierarchy when it
  matches a thrown exception against the `doCatch` blocks. The reason is
  that many times the original caused exceptions is wrapped by other
  wrapper exceptions, typically transposing the exception from a checked
  to a runtime exception.
  Camel for instance does this by wrapping it in a `RuntimeCamelException`.
  So if the original caused exception is an `java.io.IOException` then
  Camel will still match a `doCatch` block defined with an
  `java.io.IOException`. And just like Java the order in which you have
  multiple `doCatch` blocks matters. Camel will iterate from the top going
  down and use the first `doCatch` that matches the exception. The reason
  is to keep it similar to the regular java and how it selects a catch
  block. This differs from the xref:exception-clause.adoc[Exception
  Clause] that has a more intelligent exception selection strategy among
  multiple `onException` definitions, where it also considers the delta in
  the exception hierarchy to select the best definition.
  
  A third feature is that you can attach a `onWhen` predicate to signal if
  the catch should trigger or not at runtime.
  
  [[TryCatchFinally-UsingtrycatchfinallyinJavaDSL]]
  == Using try .. catch .. finally in Java DSL
  