Mule Dev 301 · 9 min read

MuleSoft error handling: On Error Continue vs On Error Propagate

By the MulePrep team · Updated June 2026

In Mule 4, the difference between On Error Continue and On Error Propagate is what happens to the owning scope after the handler runs. On Error Continue marks the scope as successful and returns the handler's result to the caller. On Error Propagate re-throws the error to the next level up, so the scope fails and the error keeps bubbling. Both run their handler logic - the split is in what the caller sees afterward. Getting that distinction right is one of the most reliable ways to gain points on the Developer II exam.

Error handling in Mule 4

Mule 4 replaced the older catch/choice/rollback exception strategies with a single, consistent model. When a processor raises an error, Mule looks for an error handler attached to the scope that owns that processor. An error handler is a container for one or more on-error components, and it is built into both the Flow component and the Try scope.

Two on-error components do the actual work, and they are the subject of this guide:

• On Error Continue - handle the error and report the owning scope as successful.
• On Error Propagate - handle the error and then re-throw it to the next level up.

Error types and matching

Every Mule error has a type, written as NAMESPACE:IDENTIFIER - for example HTTP:NOT_FOUND or DB:CONNECTIVITY. Types form a hierarchy: a connector defines specific types that roll up into broader parents, and ANY sits at the top of the matchable tree. An on-error component can match on a list of types, on a when expression such as error.cause.message contains "fatal", or on both.

Matching is ordered. Mule evaluates the on-error components top to bottom and runs the first one whose condition is satisfied - not the best fit, the first fit. That ordering is itself a frequent source of exam questions, so put your most specific types above your catch-all entries.

On Error Continue: the caller sees success

When an error reaches an On Error Continue component, the handler runs and then, in MuleSoft's own words, it "uses the result of the execution as the result of its owner, as if the owner completed the execution successfully." The message the handler produces becomes the output of the owning scope, and the caller receives that output as a success. No error leaves the scope.

The important and frequently missed detail: On Error Continue does not resume the flow at the step that failed. The processors that came after the failed step inside the same owning scope are skipped. The handler runs, its result becomes the scope result, and control passes to whatever sits after the scope - not back into the middle of it.

Any transaction the owner manages is committed on Continue, because the owner is treated as having finished cleanly.

A small On Error Continue example

Suppose an HTTP request to a pricing service fails with HTTP:TIMEOUT. Wrapping that request in a Try scope with an On Error Continue handler lets you set a default price and return a valid response:

<try>
  <http:request config-ref="Pricing" path="/price" method="GET"/>
  <error-handler>
    <on-error-continue type="HTTP:TIMEOUT">
      <set-payload value='#[{ "price": 0, "source": "fallback" }]'/>
    </on-error-continue>
  </error-handler>
</try>

The Try scope completes successfully with the fallback payload, and the flow proceeds to the next processor after the Try. The caller never learns that the pricing service timed out.

On Error Propagate: the error bubbles up

On Error Propagate also runs its handler logic first - so you can still log, enrich, or transform the error payload. The difference is what happens next. After the handler finishes, On Error Propagate "propagates the error to a higher level, such as a containing scope or external flow," and the owning scope is reported as failed.

Because the error is re-thrown, it keeps travelling up: a Try scope propagates to its parent flow, and a flow propagates to its caller (a Flow Reference, an HTTP listener that turns it into an error response, and so on). If nothing higher up catches it, it surfaces as a runtime error.

Any transaction the owner manages is rolled back on Propagate, which is the behavior you usually want when a write must not be left half-finished.

Side-by-side decision table

This is the comparison worth memorising. It answers the three questions an exam item almost always tests: does the owning scope succeed, does the error bubble up, and what happens to a transaction.

The Try scope and where handlers live

Error handlers exist at two levels, and knowing the difference is the heart of the Try-scope-vs-error-handler question. The flow-level error handler sits at the bottom of a flow and owns the whole flow. The Try scope wraps a smaller group of processors and gives just that group its own error handler.

The scope that owns the failing processor decides which handler runs and what "the owner" means for Continue and Propagate. A failure inside a Try is owned by the Try; a failure anywhere else in the flow is owned by the flow.

Why the Try scope is the natural home for On Error Continue

Here is the practical reason the Try scope exists. If you put On Error Continue on the whole flow, the flow ends right there - everything after the failed step is skipped, because Continue makes the owner (the flow) complete. That is rarely what people expect when they read the word "Continue."

Wrap the risky operation in a Try scope instead, and On Error Continue makes only the Try complete successfully. Execution then resumes at the next processor after the Try, and the rest of the flow runs normally. So the way you actually keep a flow going past a recoverable error is a Try scope with On Error Continue - not a flow-level handler.

Common exam traps

These are the recurring ways the Developer II exam catches people on this topic.

• Assuming "Continue" means "keep running the flow from where it broke." It does not. Continue completes the owning scope and skips the rest of that scope. Only a Try scope lets the flow resume after the wrapped step.
• Confusing which result the caller receives. With Continue, the caller gets the handler's output as a success, not the original payload and not an error. If a question shows a flow returning a clean response after a failure, that is Continue.
• Thinking Continue suppresses everything. Continue only handles errors that match one of its on-error components. An unmatched error type still propagates as if no handler caught it.
• Forgetting that both handlers run their body. Propagate is not "do nothing and throw." It executes its logic - logging, transforming - and then re-throws.
• Missing the transaction consequence. Continue commits the owner's transaction; Propagate rolls it back. A question framed around data integrity is usually testing this.
• Mixing up match order. The first matching on-error component wins, evaluated top to bottom - not the most specific one.

Error handling sits squarely inside the MuleSoft Certified Developer - Level 2 (Developer II) exam, which - like every exam in the track - is 60 multiple-choice questions in 120 minutes with a 70% pass mark. Developer I is recommended preparation rather than a hard prerequisite; the exam fee for Developer I and Developer II is USD 200 each as of June 2026. Always confirm the current outline, prerequisites, and fee on the official Developer II credential page before booking.