---
title: "Handling Errors"
icon: "arrow-rotate-right"
---

![](https://assets-docs.dify.ai/2024/12/6e2655949889d4d162945d840d698649.png)
[LLM](/en/guides/workflow/node/llm), [HTTP](/en/guides/workflow/node/http-request), [Code](/en/guides/workflow/node/code), and [Tool](/en/guides/workflow/node/tools) 
nodes support error handling out-of-box. When a node fails, it can take one of the three behaviors below:

<AccordionGroup>
  <Accordion title="None">
    The default behavior. When a node fails, the whole workflow stops. You get the original error message.

    Use this when:
    - You're testing and want to see what broke
    - The workflow can't continue without this step
  </Accordion>
  <Accordion title="Default Value">
    When a node fails, use a backup value instead. The workflow keeps running.

    ![](https://assets-docs.dify.ai/2024/12/e9e5e757090679243e0c9976093c7e6c.png)

    **Requirements**
    - The default value must match the node's output type -- if it outputs a string, your default must be a string.

    **Example**

    Your LLM node normally returns analysis, but sometimes it fails due to rate limits. Set a default value like:

    ```
    "Sorry, I'm temporarily unavailable. Please try again in a few minutes."
    ```

    Now users get a helpful message instead of a broken workflow.
  </Accordion>
  <Accordion title="Fail Branch">
    When a node fails, trigger a separate flow to handle the error.

    ![](https://assets-docs.dify.ai/2024/12/e5ea1af947818bd9e27cab3042c1c4f3.png)

    The fail branch is highlighted in orange. You can:
    - Send error notifications
    - Try a different approach
    - Log the error for debugging
    - Use a backup service
    **Example**

    Your main API fails, so the fail branch calls a backup API instead. Users never know there was a problem.
  </Accordion>
</AccordionGroup>

## Error in Loop/Iteration Nodes

When child nodes fail inside loops and iterations, these control flow nodes have their own error behaviors.

**Loop nodes** always stop immediately when any child node fails. The entire loop terminates and returns the error, preventing any further iterations from running.

**Iteration nodes** let you choose how to handle child node failures through the error handling mode setting:

- `terminated` - Stops processing immediately when any item fails (default)
- `continue-on-error` - Skips the failed item and continues with the next one
- `remove-abnormal-output` - Continues processing but filters out failed items from the final output

When you set an iteration to `continue-on-error`, failed items return `null` in the output array. When you use `remove-abnormal-output`, the output array only contains successful results, making it shorter than the input array.

## Error variables

When using default value or fail branch, you get two special variables:

- `error_type` - What kind of error happened (see [Error Types](en/guides/workflow/error-handling/error-type))
- `error_message` - The actual error details

Use these to:
- Show users helpful messages
- Send alerts to your team
- Choose different recovery strategies
- Log errors for debugging

**Example**

```
{% if error_type == "rate_limit" %}
Too many requests. Please wait a moment and try again.
{% else %}
Something went wrong. Our team has been notified.
{% endif %}
```

