> For the complete documentation index, see [llms.txt](https://docs.skyone.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skyone.cloud/english/skyone-studio/integrations/flows/flow-management/flow-canva-configuring-and-editing-the-flow/exception-handler/exception-handler-configuration.md). # Exception Handler - Configuration To set up an **"Exception Handler"**you need to define it within a flow and apply it to the modules. You may also need to set up the syslog server and email notification. *** #### How to access On the flow editing page, select the "**Exception Handlers"** button.
*** **Goals** Set up exception handling for a REST module. 1. **\[ Step 01 ]** [Create the HTTP Error Handler Exception](#step-01-create-the-http-error-handler-exception) 2. **\[ Step 02 ]** [Create the Generic Error Handler](#step-02-create-the-generic-error-handler) 3. **\[ Step 03 ]** [Apply Exception Handlers in the Module](#step-03-apply-exception-handlers-in-the-module) 4. **\[ Step 04 ]** [Set up the syslog server](#step-04-set-up-the-syslog-server) 5. **\[ Step 05 ]** [Run the flow](#step-05-run-the-flow) *** **Step by Step** #### **Step 01: Create the HTTP Error Handler Exception** Click "**Add Exception Handler".**
The screen appears: * Define a name for your Exception Handler, for example **HTTP Handler.** This name will be seen in the module configuration. * Set a scope of availability of your EH. * **Flow:** Viewed and available only in the flow you are editing * **Integration:** Viewed and available for all flows of the Integration you are editing * **Space:** Available for any flow of any integration in your organization * Click "**Add Rule"** to create a new **Exception Rule**.

Screen for entering Handler data

After clicking "**Add Rule"**, the second part of the settings (Handler Rules) will appear:
* Define a name for your Handler Rule, such as **Client/Server Error Responses**. * Set the **number of retries** to **1**. The goal is to allow Skyone Studio to retry the call once, helping to eliminate occasional communication errors. * Set the **wait time** (delay) before the retry. * Define the **regular expression** that identifies any HTTP client or server error. To do this, use a regular expression that matches any three-digit sequence starting with 4 or 5. Note that **every character, including spaces, is important for the correct functioning of a regular expression**. `“status”: [45]\d\d` {% hint style="info" %} You can find regular expression validators on the internet, e.g: [![](https://regex101.com/static/assets/icon-16.png)regex101: build, test, and debug regex](https://regex101.com/) {% endhint %} * Select the **notifications** that this ER will generate, for example syslog and Local. * Define the **message** generated in these notifications, for example: **HTTP Error 400/500**. This message can be filtered in syslog or local logs. Essa Regra do Handler pode ser sumarizada pelo quadro abaixo: | **Name** | **Retries** | **Delay** | **REGEX** | **ANY** | **Notification** | **Message** | **Send parameters** | | ----------------------------- | ----------- | --------- | -------------------- | ------- | ------------------------- | ------------------ | ------------------- | | Client/Server Error Responses | 1 | 0 | `“status”: [45]\d\d` | |

syslog

local

| HTTP Error 400/500 | | Next, **Handler default rule**: * Specify the **notifications** that will be generated, for example syslog and Local. * Specify the **notification message**, for example: **HTTP FATAL ERROR**. * Select **Send parameters in the message?**. This option will include all the context information of the call in the notification message, allowing you to identify exactly the parameters used. * Choose the **Final Action** (Continue, Continue loop or Stop). * Click **Save** to apply your settings. #### **Step 02: Create the Generic Error Handler** A lot of errors are unpredictable. We can define an EH to handle them in a standardized way. * Create a new EH with name **Generic** with scope Integration * Add the following **Exception Rule**: | **Name** | **Retries** | **Delay** | **REGEX** | **ANY** | **Notification** | **Message** | **Send Params** | | -------- | ----------- | --------- | --------- | ------- | ------------------------- | ------------- | --------------- | | Generic | 1 | 0 | | |

syslog

local

| UNKNOWN ERROR | | * Observe que selecionamos o campo **ANY**. Com essa opção qualquer exceção será tratada por essa regra. Tipicamente essa opção é aplicada apenas uma vez no final de uma sequência de EHs * Notice that we have selected the **ANY** field. With this option any exception will be handled by this rule. Typically this option is applied only once at the end of a sequence of EHs to handle all errors that were not specifically defined earlier. * Set the **Default Action** * Select Syslog and Local as notification mechanisms * Select **Send parameters in the message?**. This option will allow us to investigate the details of the unknown error that generated the exception. * Select the final action with "**Stop"**. In this way the flow will be stopped, because we are dealing with some serious error that our flow is not prepared to respond to. * Click "**Save"** to finish your settings.
#### **Step 03: Apply Exception Handlers in the Module** Enter the edit mode of the module that will receive the Exception Handlers. Note that both EH created are available for application in the module.
* First select HTTP Handler and then select Generic. * Note that they are inserted into the Selected Handlers field in the order in which they were selected. This order also determines the order in which exceptions will be evaluated and is therefore critical to the correct operation of the EH stack.

Exception Handlers applied to the module

#### **Step 04: Set up syslog and email notifications for the Exception Handler** When creating a rule in the Exception Handler, you can choose which message(s) you will receive.\ However, simply selecting the message type is not enough to ensure you receive the notification.\ To receive all notifications, follow these steps: 1. Go to "**Settings**" in the flow editing area. 2. Click on the "**Alerts**" tab. 3. In "**Log Settings**," enter the syslog server address and/or the email addresses that should receive the notifications. 4. Finally, click "**Save changes**." {% hint style="warning" %} It's essential that the "**Flows**" option is enabled in "**Element Notifications**." Read the article "[Notifications](/english/skyone-studio/overview/settings-and-preferences/notifications.md#alerts)." {% endhint %}
#### **Step 05: Run the flow** Execute this flow against some service that is programmed to respond with an error code (400) or make the error through some wrongly configured parameter. * Execute the flow against a service that responds to error code, for example 400. * Notice that the flow completes successfully despite the exception, since it was handled with a continue action. * Note that the locally generated log messages point out that the EH **HTTP Handler** was responsible for handling the exception. * Note that two requests were generated, one retry, with their respective notifications. The third error message was generated by **Default Action** and includes the details of the call that generated the exception. * Additionally you can run this flow against a service that is unavailable. In this case we will not get an HTTP code, but some other kind of error. The example below was generated against a server with the service disabled. * Notice the **Connection Refused** error in the detailed message. * Note that the handling of this error was done by EH **Generic**. * The flow was stopped by generating an ERROR as programmed in the Handler through the **Stop** action of the **Default Action**. *** **Next step:** [Exception Handler - Cases](/english/skyone-studio/integrations/flows/flow-management/flow-canva-configuring-and-editing-the-flow/exception-handler/exception-handler-cases.md) *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.skyone.cloud/english/skyone-studio/integrations/flows/flow-management/flow-canva-configuring-and-editing-the-flow/exception-handler/exception-handler-configuration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.