<commit_before>[[ErrorHandler-ErrorHandler]]
= Error Handler

Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-base/current/org/apache/camel/processor/ErrorHandler.html[ErrorHandler]
strategies to deal with errors processing an xref:{eip-vc}:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer].

An alternative is to specify the error handling directly in the xref:dsl.adoc[DSL]
using the xref:exception-clause.adoc[Exception Clause].

== Exception Clause

Using Error Handler combined with
Exception Clause is a very powerful
combination. We encourage end-users to use this combination in your
error handling strategies. See samples and
Exception Clause.

== Using try ... catch ... finally

Related to error handling is the xref:try-catch-finally.adoc[Try Catch
Finally] as DSL you can use directly in your route. Its basically a
mimic of the regular try catch finally in the Java language but with
more power.

The current implementations Camel provides out of the box are:

== Non transacted

* DefaultErrorHandler is the default
error handler in Camel. This error handler does not support a dead
letter queue, it will propagate exceptions back to the caller, as if
there were no error handler at all. It has a limited set of features.
* Dead Letter Channel which supports
attempting to redeliver the message exchange a number of times before
sending it to a dead letter endpoint
* NoErrorHandler for no error handling

== Transacted

* TransactionErrorHandler is the
default error handler in Camel for transacted routes. See the
Transactional Client EIP pattern.

These error handlers can be applied in the DSL to an
entire set of rules or a specific routing rule as we show in the next
examples. Error handling rules are inherited on each routing rule within
a single RouteBuilder

== Short Summary of the provided Error Handlers

=== DefaultErrorHandler

The DefaultErrorHandler is the default
error handler in Camel. Unlike xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel] it does not have any dead letter queue, and do *not* handle
exceptions by default.

=== Dead Letter Channel

The Dead Letter Channel will redeliver at
most 6 times using 1 second delay, and if the exchange failed it will be
logged at ERROR level.

You can configure the default dead letter endpoint to use:
or in XML DSL:

[source,xml]
--------------------------------------------------------------------------------------------------
<camel:errorHandler id="deadLetterErrorHandler" type="DeadLetterChannel" deadLetterUri="log:dead">

<camel:camelContext errorHandlerRef="deadLetterErrorHandler">
  ...
</camel:camelContext>
--------------------------------------------------------------------------------------------------

=== No Error Handler

The no error handler is to be used for disabling error handling.

[source,java]
-------------------------------
errorHandler(noErrorHandler());
-------------------------------

or in XML DSL:

[source,xml]
---------------------------------------------------------------
<camel:errorHandler id="noErrorHandler" type="NoErrorHandler"/>

<camel:camelContext errorHandlerRef="noErrorHandler">
  ...
</camel:camelContext>
---------------------------------------------------------------

=== TransactionErrorHandler

The TransactionErrorHandler is the
default error handler in Camel for transacted routes.

TIP:If you have marked a route as transacted using the *transacted* DSL then
Camel will automatically use a
TransactionErrorHandler. It will try
to lookup the global/per route configured error handler and use it if
it is a `TransactionErrorHandlerBuilder` instance. If not Camel will
automatically create a temporary
TransactionErrorHandler that
overrules the default error handler. This is convention over
configuration.

== Features support by various Error Handlers

Here is a breakdown of which features are supported by the
Error Handler(s):

[width="100%",cols="20%,80%",options="header",]
|=======================================================================
|Feature |Supported by the following Error Handler

|all scopes |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|onException |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|onWhen |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|continued |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|handled |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|Custom ExceptionPolicy |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|useOriginalBody |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|retryWhile |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|onRedelivery |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|RedeliveryPolicy |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|asyncDelayedRedelivery |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|redeliverWhileStopping |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|dead letter queue |Dead Letter Channel

|onPrepareFailure |DefaultErrorHandler,
Dead Letter Channel

|=======================================================================

See xref:exception-clause.adoc[Exception Clause] documentation for
additional documentation of the faatures above.

== Scopes

The error handler is scoped as either:

- CamelContext - _Globally_ in XML or _globally only_ within the same `RouteBuilder` in Java DSL
- Route - _Individually per route_

The following example shows how you can register a global error handler for the `RouteBuilder`:

[source,java]
---------------------------------------------------------------
RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("seda:error"));

        // here is our regular route
        from("seda:a").to("seda:b");
    }
};
---------------------------------------------------------------

The following example shows how you can register a route specific error
handler

[source,java]
---------------------------------------------------------------
RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // this route is using a nested error handler
        from("seda:a")
            // here we configure the error handler
            .errorHandler(deadLetterChannel("seda:error"))
            // and we continue with the routing here
            .to("seda:b");

        // this route will use the default error handler
        from("seda:b").to("seda:c");
    }
};
---------------------------------------------------------------

== Spring based configuration

*Java DSL vs. Spring DSL*
The error handler is configured a bit differently in Java DSL and Spring
DSL. Spring DSL relies more on standard Spring bean configuration
whereas Java DSL uses fluent builders.

The error handler can be configured as a spring bean and scoped in:

* global (the `<camelContext>` tag)
* per route (the `<route>` tag)
* or per policy (the `<policy>`/`<transacted>` tag)

The error handler is configured with the `errorHandlerRef` attribute.

TIP: *Error Handler Hierarchy* +
The error handlers is inherited, so if you only have set a global error
handler then its use everywhere. But you can override this in a route
and use another error handler.

=== Spring based configuration sample

In this sample we configure a xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel] on the route that should redeliver at most 3 times and use a
little delay before retrying. First we configure the reference to *myDeadLetterErrorHandler* using
the `errorHandlerRef` attribute on the `route` tag.

[source,xml]
----
    <camelContext xmlns="http://camel.apache.org/schema/spring">
        <template id="myTemplate"/>
		<!-- set the errorHandlerRef to our DeadLetterChannel, this applies for this route only -->
        <route errorHandlerRef="myDeadLetterErrorHandler">
            <from uri="direct:in"/>
            <process ref="myFailureProcessor"/>
            <to uri="mock:result"/>
        </route>
    </camelContext>
----

Then we configure *myDeadLetterErrorHandler* that is our
Dead Letter Channel. This configuration
is standard Spring using the bean element.
And finally we have another spring bean for the redelivery policy where
we can configure the options for how many times to redeliver, delays
etc.

[source,xml]
----
    <!-- here we configure our DeadLetterChannel -->
	<bean id="myDeadLetterErrorHandler" class="org.apache.camel.builder.DeadLetterChannelBuilder">
	    <!-- exchanges is routed to mock:dead in cased redelivery failed -->
        <property name="deadLetterUri" value="mock:dead"/>
		<!-- reference the redelivery policy to use -->
        <property name="redeliveryPolicy" ref="myRedeliveryPolicyConfig"/>
    </bean>

    <!-- here we set the redelivery settings -->
	<bean id="myRedeliveryPolicyConfig" class="org.apache.camel.processor.errorhandler.RedeliveryPolicy">
	    <!-- try redelivery at most 3 times, after that the exchange is dead and its routed to the mock:dead endpoint -->
        <property name="maximumRedeliveries" value="3"/>
		<!-- delay 250ms before redelivery -->
        <property name="redeliveryDelay" value="250"/>
    </bean>
----

== Using the transactional error handler

The transactional error handler is based on spring transaction. This
requires the usage of the camel-spring or camel-jta component.

See xref:{eip-vc}:eips:transactional-client.adoc[Transactional Client] that has many
samples for how to use and transactional behavior and configuration with
this error handler.

<commit_msg>Update error-handler.adoc<commit_after>[[ErrorHandler-ErrorHandler]]
= Error Handler

Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-base/current/org/apache/camel/processor/ErrorHandler.html[ErrorHandler]
strategies to deal with errors processing an xref:{eip-vc}:eips:eventDrivenConsumer-eip.adoc[Event Driven Consumer].

An alternative is to specify the error handling directly in the xref:dsl.adoc[DSL]
using the xref:exception-clause.adoc[Exception Clause].

== Exception Clause

Using Error Handler combined with
Exception Clause is a very powerful
combination. We encourage end-users to use this combination in your
error handling strategies. See samples and
Exception Clause.

== Using try ... catch ... finally

Related to error handling is the xref:try-catch-finally.adoc[Try Catch
Finally] as DSL you can use directly in your route. Its basically a
mimic of the regular try catch finally in the Java language but with
more power.

The current implementations Camel provides out of the box are:

== Non transacted

* DefaultErrorHandler is the default
error handler in Camel. This error handler does not support a dead
letter queue, it will propagate exceptions back to the caller, as if
there were no error handler at all. It has a limited set of features.
* Dead Letter Channel which supports
attempting to redeliver the message exchange a number of times before
sending it to a dead letter endpoint
* NoErrorHandler for no error handling

== Transacted

* TransactionErrorHandler is the
default error handler in Camel for transacted routes. See the
Transactional Client EIP pattern.

These error handlers can be applied in the DSL to an
entire set of rules or a specific routing rule as we show in the next
examples. Error handling rules are inherited on each routing rule within
a single RouteBuilder

== Short Summary of the provided Error Handlers

=== DefaultErrorHandler

The DefaultErrorHandler is the default
error handler in Camel. Unlike xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel] it does not have any dead letter queue, and do *not* handle
exceptions by default.

=== Dead Letter Channel

The Dead Letter Channel will redeliver at
most 6 times using 1 second delay, and if the exchange failed it will be
logged at ERROR level.

You can configure the default dead letter endpoint to use:
or in XML DSL:

[source,xml]
--------------------------------------------------------------------------------------------------
<camel:errorHandler id="deadLetterErrorHandler" type="DeadLetterChannel" deadLetterUri="log:dead">

<camel:camelContext errorHandlerRef="deadLetterErrorHandler">
  ...
</camel:camelContext>
--------------------------------------------------------------------------------------------------

=== No Error Handler

The no error handler is to be used for disabling error handling.

[source,java]
-------------------------------
errorHandler(noErrorHandler());
-------------------------------

or in XML DSL:

[source,xml]
---------------------------------------------------------------
<camel:errorHandler id="noErrorHandler" type="NoErrorHandler"/>

<camel:camelContext errorHandlerRef="noErrorHandler">
  ...
</camel:camelContext>
---------------------------------------------------------------

=== TransactionErrorHandler

The TransactionErrorHandler is the
default error handler in Camel for transacted routes.

TIP:If you have marked a route as transacted using the *transacted* DSL then
Camel will automatically use a
TransactionErrorHandler. It will try
to lookup the global/per route configured error handler and use it if
it is a `TransactionErrorHandlerBuilder` instance. If not Camel will
automatically create a temporary
TransactionErrorHandler that
overrules the default error handler. This is convention over
configuration.

== Features support by various Error Handlers

Here is a breakdown of which features are supported by the
Error Handler(s):

[width="100%",cols="20%,80%",options="header",]
|=======================================================================
|Feature |Supported by the following Error Handler

|all scopes |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|onException |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|onWhen |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|continued |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|handled |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|Custom ExceptionPolicy |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|useOriginalBody |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|retryWhile |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|onRedelivery |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|RedeliveryPolicy |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|asyncDelayedRedelivery |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|redeliverWhileStopping |DefaultErrorHandler,
TransactionErrorHandler,
Dead Letter Channel

|dead letter queue |Dead Letter Channel

|onPrepareFailure |DefaultErrorHandler,
Dead Letter Channel

|=======================================================================

See xref:exception-clause.adoc[Exception Clause] documentation for
additional documentation of the features above.

== Scopes

The error handler is scoped as either:

- CamelContext - _Globally_ in XML or _globally only_ within the same `RouteBuilder` in Java DSL
- Route - _Individually per route_

The following example shows how you can register a global error handler for the `RouteBuilder`:

[source,java]
---------------------------------------------------------------
RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("seda:error"));

        // here is our regular route
        from("seda:a").to("seda:b");
    }
};
---------------------------------------------------------------

The following example shows how you can register a route specific error
handler

[source,java]
---------------------------------------------------------------
RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // this route is using a nested error handler
        from("seda:a")
            // here we configure the error handler
            .errorHandler(deadLetterChannel("seda:error"))
            // and we continue with the routing here
            .to("seda:b");

        // this route will use the default error handler
        from("seda:b").to("seda:c");
    }
};
---------------------------------------------------------------

== Spring based configuration

*Java DSL vs. Spring DSL*
The error handler is configured a bit differently in Java DSL and Spring
DSL. Spring DSL relies more on standard Spring bean configuration
whereas Java DSL uses fluent builders.

The error handler can be configured as a spring bean and scoped in:

* global (the `<camelContext>` tag)
* per route (the `<route>` tag)
* or per policy (the `<policy>`/`<transacted>` tag)

The error handler is configured with the `errorHandlerRef` attribute.

TIP: *Error Handler Hierarchy* +
The error handlers is inherited, so if you only have set a global error
handler then its use everywhere. But you can override this in a route
and use another error handler.

=== Spring based configuration sample

In this sample we configure a xref:{eip-vc}:eips:dead-letter-channel.adoc[Dead Letter
Channel] on the route that should redeliver at most 3 times and use a
little delay before retrying. First we configure the reference to *myDeadLetterErrorHandler* using
the `errorHandlerRef` attribute on the `route` tag.

[source,xml]
----
    <camelContext xmlns="http://camel.apache.org/schema/spring">
        <template id="myTemplate"/>
		<!-- set the errorHandlerRef to our DeadLetterChannel, this applies for this route only -->
        <route errorHandlerRef="myDeadLetterErrorHandler">
            <from uri="direct:in"/>
            <process ref="myFailureProcessor"/>
            <to uri="mock:result"/>
        </route>
    </camelContext>
----

Then we configure *myDeadLetterErrorHandler* that is our
Dead Letter Channel. This configuration
is standard Spring using the bean element.
And finally we have another spring bean for the redelivery policy where
we can configure the options for how many times to redeliver, delays
etc.

[source,xml]
----
    <!-- here we configure our DeadLetterChannel -->
	<bean id="myDeadLetterErrorHandler" class="org.apache.camel.builder.DeadLetterChannelBuilder">
	    <!-- exchanges is routed to mock:dead in cased redelivery failed -->
        <property name="deadLetterUri" value="mock:dead"/>
		<!-- reference the redelivery policy to use -->
        <property name="redeliveryPolicy" ref="myRedeliveryPolicyConfig"/>
    </bean>

    <!-- here we set the redelivery settings -->
	<bean id="myRedeliveryPolicyConfig" class="org.apache.camel.processor.errorhandler.RedeliveryPolicy">
	    <!-- try redelivery at most 3 times, after that the exchange is dead and its routed to the mock:dead endpoint -->
        <property name="maximumRedeliveries" value="3"/>
		<!-- delay 250ms before redelivery -->
        <property name="redeliveryDelay" value="250"/>
    </bean>
----

== Using the transactional error handler

The transactional error handler is based on spring transaction. This
requires the usage of the camel-spring or camel-jta component.

See xref:{eip-vc}:eips:transactional-client.adoc[Transactional Client] that has many
samples for how to use and transactional behavior and configuration with
this error handler.


{'fraction_non_alphanumeric': 0.14863196873071385, 'fraction_numerical': 0.0018514708907632176, 'mean_word_length': 3.350111856823266, 'pattern_counts': {'":': 0, '<': 69, '<?xml version=': 0, '>': 69, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 10}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1559125', 'n_tokens_mistral': 4884, 'n_tokens_neox': 4661, 'n_words': 2009}