ESBExit

Rethrow

Re-raises the fault being handled, preserving its type and data. The generator constructs a new technical fault instead, which changes both the type and where the error goes.

Translated com.tibco.pe.core.RethrowActivity

What it does in BusinessWorks

Rethrow takes no configuration and no input. It re-raises the fault currently being handled in the catch branch it sits in, with the same fault name and the same data it arrived with, so an outer catch or the calling process sees the original rather than a substitute.

The pattern it belongs to is narrow and common: catch everything, log it or write a checkpoint, then put the fault back so the caller still fails. Read that way, a Rethrow is a statement that the catch branch was for a side effect and not for recovery.

The Camel equivalent

BusinessWorks 5.process
<pd:activity name="Rethrow">
  <pd:type>com.tibco.pe.core.RethrowActivity</pd:type>
  <pd:resourceType>ae.activities.rethrow</pd:resourceType>
  <config/>
  <pd:inputBindings/>
</pd:activity>
Apache CamelJava DSL, generated
// the whole activity, as emitted
.throwException(<technical fault>.class,
    "rethrow from Rethrow")

Where the semantics diverge

Nothing is rethrown. The rule constructs a new exception. The original type, message, data and cause are not read and do not survive, so ${exception.message} downstream reads rethrow from <activity name>. Camel has a form that does what the source meant, leaving the exchange’s exception in place or rethrowing the caught one from a processor, and the generator does not use it.

The type is laundered. A business fault caught and put back comes out as a technical one. In the generated fault policy that is not a cosmetic difference: the business class is logged and left alone, while the technical class is logged and forwarded to direct:errorEvent. A Rethrow therefore moves errors onto the technical path that the original design deliberately kept off it.

Camel already propagates. Outside an explicit doTry/doCatch, an exception in a Camel route travels outward on its own; there is nothing to put back. The emitted step is a fresh throw at a point where the source was merely declining to stop one.

It often sits in code that never runs. A Rethrow lives in a catch branch, and the generator emits catch branches as .when(simple("false")), a dead branch flagged with TODO_HUMAN. Where that applies, the Rethrow’s real effect on the migrated route is nothing at all. Catch covers why.

The work this leaves is deciding, per catch branch, whether the branch was for recovery or for a side effect. Side-effect branches map onto an onException(...).handled(false) clause with the logging inside it, and the Rethrow disappears rather than being translated.

What the toolchain does

An unconditional rule, so nothing is marked. It emits .throwException(<technical fault>.class, "rethrow from <activity name>") and reads neither the enclosing catch nor the fault in flight. The two exception classes belong to the platform the routes are generated into rather than to the generator, so this page names their roles and not the classes.

Related activities