# Using Error Policies

In addition to the dead letter queues provided by Kafka Connect, the Stream Reactor sink connectors support Error Policies to handle failure scenarios.

The sinks have three error policies that determine how failed writes to the target database are handled. These error policies allow you to control the behaviour of the sink if it encounters an error when writing records to the target system. Since Kafka retains the records, subject to the configured retention policy of the topic, the sink can ignore the error, fail the connector or attempt redelivery.

<table><thead><tr><th width="239">Name</th><th width="356.3333333333333">Description</th><th>Default Value</th></tr></thead><tbody><tr><td>[connector-prefix].error.policy</td><td>Specifies the action to be taken if an error occurs while inserting the data. There are three available options, NOOP, the error is swallowed, THROW, the error is allowed to propagate and retry. For RETRY the Kafka message is redelivered up to a maximum number of times specified by the [connector-prefix].max.retries option</td><td>THROW</td></tr><tr><td>[connector-prefix].max.retries</td><td>The maximum number of times a message is retried. Only valid when the [connector-prefix].error.policy is set to RETRY</td><td>10</td></tr><tr><td>[connector-prefix].retry.interval</td><td>The interval, in milliseconds between retries, if the sink is using [connector-prefix].error.policy set to RETRY</td><td>60000</td></tr></tbody></table>

## Throw  <a href="#throw" id="throw"></a>

Any error in writing to the target system will be propagated up and processing is stopped. This is the default behaviour.

## Noop  <a href="#noop" id="noop"></a>

Any error in writing to the target database is ignored and processing continues.

Keep in mind\
This can lead to missed errors if you don’t have adequate monitoring. Data is not lost as it’s still in Kafka subject to Kafka’s retention policy. The sink currently does not distinguish between integrity constraint violations and or other exceptions thrown by any drivers or target systems.

## Retry  <a href="#retry" id="retry"></a>

Any error in writing to the target system causes the RetryIterable exception to be thrown. This causes the Kafka Connect framework to pause and replay the message. Offsets are not committed. For example, if the table is offline it will cause a write failure, and the message can be replayed. With the Retry policy, the issue can be fixed without stopping the sink.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.lenses.io/latest/connectors/tutorials/using-error-policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.