Claus Ibsen created CAMEL-25114:
-----------------------------------

             Summary: camel-core - doTry, doCatch and doFinally: fix bugs found 
in a deep review
                 Key: CAMEL-25114
                 URL: https://issues.apache.org/jira/browse/CAMEL-25114
             Project: Camel
          Issue Type: Bug
          Components: camel-core
            Reporter: Claus Ibsen


A review of doTry, doCatch and doFinally found these bugs:

# An exception from the onWhen predicate of a doCatch is not propagated and the 
exchange never completes (doFinally is not executed and a synchronous caller 
waits forever).
# In the Java DSL, {{onWhen}} on a doCatch is set on every doCatch of the doTry 
(including the doCatch blocks of nested doTry blocks), so the onWhen of a later 
doCatch replaces the onWhen of the earlier doCatch blocks.
# A nested doTry (or a doTry in a route called from a doTry) removes the try 
block marker ({{TryRouteBlock}}) when it completes, instead of restoring it. 
Steps after it in the outer doTry, such as recipientList, multicast and split, 
then use the route error handler (redelivery and dead letter channel), and the 
doCatch of the outer doTry is not used.
# An exception thrown in doFinally while an earlier exception is not handled is 
lost. The original exception is now kept and the doFinally exception is added 
as suppressed.
# The doFinally (also the implicit doFinally) removes the failure details 
({{Exchange.FAILURE_ROUTE_ID}}, {{FAILURE_NODE_ID}}, {{FAILURE_ENDPOINT}}, 
{{FAILURE_LOCATION}}) of an earlier failure that happened before the doTry.
# The check that a doTry must have one or more doCatch or doFinally blocks 
never fails (the list of catch clauses is never null), so a doTry without them 
is accepted, which silently turns off the route error handler for its steps. 
Such a doTry now fails to start.
# A doCatch after a doCatch that already handled the exception still evaluates 
its onWhen and updates its counters.
# The step id (CAMEL-23616) is not set on the doCatch and doFinally processors.

The documentation now describes how doCatch matches an exception (clause order, 
differs from onException), that an exception that escapes a doTry is not 
handled by the route error handler, and that stop() skips doFinally.

Not changed:
* The circuit breaker processors (camel-resilience4j, 
camel-microprofile-fault-tolerance) also remove the TryRouteBlock marker 
instead of restoring it.
* The model accepts doTry children in any order (such as steps after a doCatch).

_Claude Code on behalf of Claus Ibsen_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to