This is an automated email from the ASF dual-hosted git repository.
aldettinger pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/master by this push:
new 6716fe0 Fixed some issues in the doTry/doCatch/doFinally documentation
6716fe0 is described below
commit 6716fe0e5a2b689f78bf40ca49693a0c64718a35
Author: aldettinger <aldettin...@gmail.com>
AuthorDate: Tue Sep 15 16:09:58 2020 +0200
Fixed some issues in the doTry/doCatch/doFinally documentation
---
.../modules/ROOT/pages/try-catch-finally.adoc | 49 ++++------------------
1 file changed, 8 insertions(+), 41 deletions(-)
diff --git a/docs/user-manual/modules/ROOT/pages/try-catch-finally.adoc
b/docs/user-manual/modules/ROOT/pages/try-catch-finally.adoc
index e9793db..385b4cc 100644
--- a/docs/user-manual/modules/ROOT/pages/try-catch-finally.adoc
+++ b/docs/user-manual/modules/ROOT/pages/try-catch-finally.adoc
@@ -3,8 +3,7 @@
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.
+It aims to work like its Java sisters but with more power.
In Camel we prefix the keywords with `do` to avoid having same keyword
as Java. So we have:
@@ -14,10 +13,6 @@ as Java. So we have:
* `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.
-
== Camel error handling is disabled
When using `doTry .. doCatch .. doFinally` then the regular Camel
@@ -36,47 +31,32 @@ block.
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 reasons is
+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 wrapped it in a `RuntimeCamelException`.
+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 matter. Camel will iterate from the top going
+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 differers from the xref:exception-clause.adoc[Exception
+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 consider the delta in
+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.
-And to simulate _rethrowing_ an exception from a `doCatch` you should
-use the `handled` predicate. If its evaluated to `false` Camel will
-reattach the exception on the xref:exchange.adoc[Exchange].
-
[[TryCatchFinally-UsingtrycatchfinallyinJavaDSL]]
== 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 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]
+https://github.com/apache/camel/tree/master/core/camel-core/src/test/java/org/apache/camel/processor/TryProcessorMultipleExceptionTest.java[TryProcessorMultipleExceptionTest.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
@@ -84,7 +64,7 @@ should be triggered or not.
In our case we only want to trigger if the caused exception message
contains the *damn* word.
-https://github.com/apache/camel/tree/master/camel-core/src/test/java/org/apache/camel/processor/TryProcessorOnWhenTest.java[TryProcessorOnWhenTest.java]
+https://github.com/apache/camel/tree/master/core/camel-core/src/test/java/org/apache/camel/processor/TryProcessorOnWhenTest.java[TryProcessorOnWhenTest.java]
=== Use end() to end the block
@@ -97,24 +77,11 @@ to indicate the end there.
[[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
should be triggered or not.
