[
https://issues.apache.org/jira/browse/CAMEL-26866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26866:
--------------------------------
Fix Version/s: 4.24.0
> camel-core - an Error of a contract transformer or validator, or in a
> transacted step, does not fail the exchange
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26866
> URL: https://issues.apache.org/jira/browse/CAMEL-26866
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
> Fix For: 4.24.0
>
>
> Follow-up of CAMEL-26741 (apache/camel#29525) and CAMEL-26824, found in our
> review of CAMEL-26824. These places still catch only {{Exception}}, so an
> {{Error}} that is not a {{VirtualMachineError}} (an {{AssertionError}}, a
> {{LinkageError}} such as {{NoClassDefFoundError}}, a custom {{Error}}) of
> user code does not fail the exchange:
> * {{ContractAdvice}}, the advice of the input and output type of a route
> ({{inputType}}, {{outputType}}): an {{Error}} of a transformer or validator
> escapes from the advice. {{CamelInternalProcessor}} catches only
> {{Exception}} around the advices, so the {{Error}} is thrown to the caller of
> the route, without the after tasks of the advices that already ran (such as
> the end of the unit of work), and the exchange can stay inflight.
> * {{CamelInternalProcessor.processTransacted}}: catches {{Exception}} and
> calls the callback in {{finally}}, so an {{Error}} that the processor of a
> transacted exchange throws from its synchronous {{process}} is thrown on
> after the callback. This is reached by a plain {{Processor}} of a transacted
> exchange in a step without an error handler of its own (in a {{doTry}},
> {{doCatch}} or {{doFinally}} block, an {{onException}}, a circuit breaker,
> the outputs of a multicast): {{DelegateSyncProcessor.process(Exchange)}} has
> no catch, so a {{doCatch}} does not get the {{Error}}, and it is thrown to
> the caller.
> Expected: as for the processor adapters after CAMEL-26741 and the processors
> of CAMEL-26824, such an {{Error}} fails the exchange, and a
> {{VirtualMachineError}} is left as before.
> The reactive executor and {{MulticastTask}} have the same gap; they need
> their own tests (parallel, streaming) and touch {{MulticastProcessor}}, which
> CAMEL-26824 changes, so they are left for a separate JIRA.
> The other advices of a route have the same gap (a separate JIRA). Found in
> our review of CAMEL-26824; confirmed with tests on the real classes.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
