Mule-Dev-201 Domain 10: Handling Errors (8%)

Overview

Mule 4 raises typed errors, each with a namespace and identifier such as HTTP:NOT_FOUND, DB:CONNECTIVITY or VALIDATION:INVALID_EMAIL. When a processor fails, the rest of the flow is skipped and the error goes to the nearest error handler: one in a Try scope, one in the flow, a global default handler, or Mule's built-in default, which logs the error and rethrows it. Each handler contains On Error Continue or On Error Propagate scopes that match error types or conditions.

The exam guide has five objectives, all phrased as applying correct processors and syntax and predicting outcomes: implement global error handlers; implement On Error Continue and On Error Propagate; combine multiple error handlers; implement Try scopes; and map custom errors. Most questions trace a failure through one or two flows and ask what the caller receives, such as which payload, which HTTP status, or whether the next processor runs.

Why it matters on the exam

Handling Errors is 8% of the exam, about five questions, but the model it tests decides answers in other sections too, from APIkit status codes to Scatter-Gather failures and validation errors. The difference between On Error Continue and On Error Propagate is the single most tested rule: one makes the flow succeed with the handler's result, the other runs the handler and then fails the flow anyway. Combined with Flow Reference and Try scopes, small changes in a diagram reverse the outcome. Strong error-handling skills also distinguish production-ready Mule applications, because clients need clear status codes and backend failures should be translated into errors the API's consumers understand.

How it's tested

Error questions are almost always predictions. A flow, often with a Flow Reference to a child flow or a Try scope, fails at a given processor. You are asked what the HTTP client receives, what a Logger prints afterwards, or which handler executes. Draw the path of the error before reading the options.

Continue or propagate

You predict the response and the flow outcome when the matching handler is On Error Continue or On Error Propagate.
Which handler catches it

Several handlers and scopes exist, and you choose the one that handles a given error type.
Map the error

A connector error must surface as a business error, and you choose error mapping or Raise Error.

Reasoning it through

Flow A has an HTTP Listener and calls private flow B through Flow Reference. B fails with HTTP:CONNECTIVITY and has On Error Propagate that sets the payload to Backend down. The error rethrows to A, whose own On Error Continue for ANY sets the payload to Try later. A therefore completes successfully, and the client receives status 200 with the body Try later. With On Error Propagate in A instead, the client would receive a 500.

Objectives 5

Official objectives from the Salesforce outline, in outline order.

10.1 Apply correct processors/syntax to implement global error handlers, and predict outcomes.Default behaviour and an application-wide default handler.

What it means: Without any handler, Mule's default error handling logs the error and propagates it; for an HTTP Listener, the client receives status 500 with the error description. You can define a global error handler as a configuration element and set it as the application's default with defaultErrorHandler-ref in the Configuration global element.
What to understand: A global default handler applies to every flow that does not define its own error handler. Flows with their own handler use that handler instead, and if no scope in it matches, default propagation applies rather than the global handler. Global handlers can also be referenced by name from individual flows. Use them to give consistent logging and responses across the application, such as mapping common errors to standard JSON error bodies.
How it shows up: You decide whether a global handler or the default behaviour handles an error in a given flow.
Common confusion: A flow that has its own error handler does not fall back to the global default for unmatched errors.

10.2 Apply correct processors/syntax to implement on-error continue and on-error propagate handlers, and predict outcomes.Handling an error so the flow succeeds, or rethrowing it.

What it means: On Error Continue runs its processors and then completes the flow as if successful, returning the handler's result to the source or caller. On Error Propagate runs its processors and then rethrows the error, so the caller or source sees a failure.
What to understand: In both cases the processors after the failing one in the flow do not run. With an HTTP Listener, On Error Continue returns a success response, 200 by default, with the handler's payload, while On Error Propagate uses the listener's error response, 500 by default. When the flow was called by Flow Reference, On Error Continue lets the caller continue after the reference with the handler's payload, while On Error Propagate passes the error to the caller's handler. Transactions are committed with Continue and rolled back with Propagate.
How it shows up: You predict the HTTP status and body, or whether the caller continues, for each scope type.
Common confusion: On Error Continue does not resume the flow at the processor after the failure; it ends the flow successfully.

10.3 Apply correct processors/syntax to combine multiple error handlers, and predict outcomes.Ordering scopes by type and when, and handlers at several levels.

What it means: An error handler can contain several On Error scopes. Mule evaluates them in order and runs the first one whose type, such as HTTP:NOT_FOUND or DB:CONNECTIVITY, or when expression matches. ANY matches every error and should come last.
What to understand: List specific types before general ones; a scope for ANY at the top hides every other scope. One scope can match several types separated by commas, and types are hierarchical, so a parent type also matches its children. Errors can pass through several levels: a Try scope handler, then the flow's handler, then the caller's handler through Flow Reference. At each level, Continue stops the error and Propagate passes it up. Read the error object with error.errorType, error.description and error.cause.
How it shows up: Several scopes with different types are shown, and you pick the one that runs for a given error.
Common confusion: If no scope in a flow's handler matches, the error propagates as with the default handler.

10.4 Apply correct processors /syntax to implement try scopes, and predict outcomes.Handling errors for a group of processors inside a flow.

What it means: A Try scope wraps one or more processors and has its own error handler. An error inside the Try is handled there first, which lets the flow treat one risky step differently from the rest. Try can also define a transaction for the processors it contains.
What to understand: If the Try's matching scope is On Error Continue, the Try completes successfully with the handler's payload and the flow continues with the processor after the Try. If it is On Error Propagate, or no scope matches, the error leaves the Try and goes to the flow's handler. A common use is wrapping the body of a For Each in a Try so one failed element does not stop the loop.
How it shows up: A failure inside a Try is shown, and you predict whether processors after the Try run.
Common confusion: Only On Error Continue inside the Try lets processing continue after the scope.

10.5 Apply correct processors/syntax to map custom errors, and predict outcomes.Error mappings on operations and the Raise Error component.

What it means: Error mapping on a connector operation translates an error type it raises into a custom type, for example HTTP:UNAUTHORIZED to APP:INVALID_CREDENTIALS. Handlers then match the custom type. The Raise Error component throws a custom error deliberately, with a type and description.
What to understand: Custom types use your own namespace, such as APP or ORDERS; reusing a connector or core namespace such as HTTP or MULE is not allowed. Mapping lets you distinguish the same underlying error from different operations, such as a connectivity failure from the inventory API versus the payment API. Mapped errors keep the original as the cause. Use ANY as the source type in a mapping to translate every error from an operation.
How it shows up: You choose the mapping or Raise Error configuration that produces a business-specific error type.
Common confusion: Error mapping is set on the operation that raises the error, not in the error handler.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

Error type

Namespace and identifier such as HTTP:NOT_FOUND or VALIDATION:NULL.

Remember
Types are hierarchical; ANY matches all.

Tested as
Matching handlers to errors.

Trap
Ignoring the namespace.
Default error handling

Logs and propagates the error when no handler exists.

Remember
HTTP Listener returns 500 with the error description.

Tested as
No-handler scenarios.

Trap
Assuming errors are silently ignored.
Global default handler

Error handler set with defaultErrorHandler-ref.

Remember
Used by flows without their own handler.

Tested as
Application-wide handling.

Trap
Expecting it to catch unmatched errors in flows with handlers.
On Error Continue

Handles the error and completes the flow successfully.

Remember
Returns the handler's payload; HTTP 200 by default.

Tested as
Most-tested rule.

Trap
Thinking the flow resumes after the failing processor.
On Error Propagate

Runs the handler, then rethrows the error.

Remember
Caller or source sees a failure; HTTP 500 by default.

Tested as
Most-tested rule.

Trap
Thinking it stops the error.
Handler order

First matching On Error scope runs.

Remember
Put ANY last.

Tested as
Multiple-scope questions.

Trap
Placing ANY first.
Try scope

Wraps processors with a local error handler.

Remember
Continue lets the flow proceed after the Try.

Tested as
Isolating risky steps.

Trap
Expecting Propagate in a Try to let the flow continue.
Error mapping

Translates an operation's error type to a custom type.

Remember
Configured on the operation.

Tested as
Custom error objective.

Trap
Trying to map inside the handler.
Raise Error

Throws a custom error with a type and description.

Remember
Useful for business-rule failures.

Tested as
Custom error scenarios.

Trap
Using a reserved namespace.
error object

Holds description, errorType, cause and errorMessage.

Remember
Read in handlers and Loggers.

Tested as
Building error responses.

Trap
Using Mule 3 exception syntax.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

On Error Continue vs On Error Propagate

Concept	Meaning	Key difference	Common trap
On Error Continue	Handles and completes the flow successfully	Caller continues; HTTP success response	Expecting remaining flow processors to run
On Error Propagate	Handles, then rethrows	Caller's handler runs; HTTP error response	Thinking the error stops at this handler

Where errors are handled

Concept	Meaning	Key difference	Common trap
Try scope handler	Handles errors from wrapped processors	Most local level	Forgetting Propagate sends errors up
Flow error handler	Handles errors anywhere in the flow	Overrides the global default for that flow	Expecting unmatched errors to reach the global handler
Global default handler	Applies to flows without their own handler	Set with defaultErrorHandler-ref	Thinking every flow uses it

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

Resume after failure

What candidates pick
Choosing the option where processors after the failing step run.

Why it looks right
Continue sounds like carry on with the flow.

Why it's wrong
On Error Continue ends the flow successfully; only processors after an enclosing Try scope run.

Clue to watch for The failure is not inside a Try.
Propagate returns success

What candidates pick
Expecting 200 when the handler is On Error Propagate.

Why it looks right
The handler set a friendly payload.

Why it's wrong
Propagate rethrows the error, so the listener sends its error response, 500 by default.

Clue to watch for The scope name is Propagate, regardless of payload.
Child Continue

What candidates pick
Expecting the parent's handler to run when the child flow used On Error Continue.

Why it looks right
An error occurred somewhere in the call chain.

Why it's wrong
The child completed successfully, so the parent continues after the Flow Reference with the child's payload.

Clue to watch for Flow Reference to a private flow with its own handler.
ANY first

What candidates pick
Expecting HTTP:NOT_FOUND scope to run when ANY is listed above it.

Why it looks right
The specific type looks like the better match.

Why it's wrong
Scopes are evaluated in order, and ANY matches first.

Clue to watch for Look at scope order, not specificity.
Global catches everything

What candidates pick
Assuming the global handler handles unmatched errors in a flow with its own handler.

Why it looks right
Global sounds universal.

Why it's wrong
A flow with its own handler uses only that handler; unmatched errors propagate.

Clue to watch for The flow defines a handler with only specific types.

Answer framework

Trace any error-handling question on the exam through these five steps.

Find the failing processor and the error type it raises, applying any error mapping configured on that operation.
Look for the closest enclosing Try scope; if present, evaluate its On Error scopes in order against the error type.
If not handled by a Try, evaluate the flow's own handler, or the global default if the flow has none, or default propagation.
Apply the matched scope: Continue completes that level successfully with the handler payload; Propagate sends the error to the next level up.
At the top flow, convert the outcome to the client response: success status for Continue, error response status for Propagate.

Practice question

A flow has an HTTP Listener, then a Try scope containing an HTTP Request that raises HTTP:TIMEOUT, then a Set Payload to Done. The Try's handler has On Error Propagate for HTTP:TIMEOUT. The flow's handler has On Error Continue for ANY that sets the payload to Fallback. What does the client receive?

Status 500 with the timeout description Status 200 with Done Status 500 with Fallback Status 200 with Fallback

Show the answer

Answer D. The Try's On Error Propagate runs and rethrows HTTP:TIMEOUT out of the Try, so Set Payload to Done never runs. The flow's handler then matches ANY with On Error Continue, sets the payload to Fallback and completes the flow successfully. The HTTP Listener therefore sends its normal response, status 200 with Fallback. A 500 would require the flow-level scope to propagate as well.

Want more like this? The Mule-Dev-201 practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Error handling is best learned by breaking things on purpose. Create a flow with an HTTP Listener and an HTTP Request to a non-existent host, then try each variation: no handler, On Error Continue, On Error Propagate, a global default handler and a Try scope around the request. Record the status code, body and which Loggers ran for each case in a table.

Next, add a private flow called through Flow Reference and repeat the experiments at both levels, including Continue in the child with Propagate in the parent and the reverse. These combinations are where most exam questions come from.

Finally, configure an error mapping that turns HTTP:CONNECTIVITY into APP:INVENTORY_DOWN and add a Raise Error for a business rule. Write handlers that match the custom types. Revisit your table during the last week of preparation, and practise tracing errors on paper without Studio until each answer takes less than a minute.

FAQ

What share of the Mule-Dev-201 exam is Handling Errors?

Handling Errors is 8% of the exam, about five of the 60 scored questions. Its rules also decide answers in APIkit, routing and record-processing questions.

What is the main difference between On Error Continue and On Error Propagate?

Continue handles the error and completes the flow successfully. Propagate runs its processors and then rethrows the error, so the caller or HTTP client sees a failure.

What does an HTTP Listener return when a flow has no error handler?

Mule's default handling logs and propagates the error, and the listener returns status 500 with the error description unless the error response is configured otherwise.

When is the global default error handler used?

Only for flows that do not define their own error handler. It is set with defaultErrorHandler-ref in the Configuration global element.

Can I use HTTP as the namespace for a custom error?

No. Custom errors need your own namespace, such as APP. Core and connector namespaces such as MULE and HTTP are reserved.

How do I keep a For Each running when one element fails?

Wrap the processors inside the For Each in a Try scope with On Error Continue. The failed element is handled, and the loop moves to the next element.

Related domains

Other CRM & Business Applications certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Mule-Dev-201 Domain 10: Handling Errors

Overview

How it's tested

Continue or propagate

Which handler catches it

Map the error

Objectives 5

High-yield concepts

Error type

Default error handling

Global default handler

On Error Continue

On Error Propagate

Handler order

Try scope

Error mapping

Raise Error

error object

Side by side

On Error Continue vs On Error Propagate

Where errors are handled

Exam traps

Resume after failure

Propagate returns success

Child Continue

ANY first

Global catches everything

Answer framework

Practice question

Checklist

Study strategy

FAQ

Other CRM & Business Applications certifications

Test your Domain 10 knowledge

Keep going