Error handling

Since any API endpoint can return an error during an execution of a scenario, Make brought a way, how to handle such errors. Therefore, all apps in Make, custom included, should have error handling implemented. This way, the modules are more transparent as users of them exactly know, what caused the error. Also, error handling in a scenario can be used.

Example of error handling

Output from API

Without error handling

With error handling

Code

Notice, that the wording of the error is now available. Thanks to this, you know where is an error and how to solve/handle it.

Copy

{
    // ...
    "response": {
        "error": {
            "message": "[{{statusCode}}] {{body.error}}"
        }
    },
    // ...
}

HTTP 4** and 5** error handling

When the response is returned with 4** or 5** HTTP Status Code, this is automatically considered an error. If the error directive is not specified, the user will see a message for the status code that was returned (List of HTTP status codes). But you are able to customize the message, shown to the user with the error or error.message directive.

Example:

{
    "response": {
        "error": {
            "type": "RuntimeError",
            "message": "[{{statusCode}}] {{body.error.message}}",
            "400": {
                "type": "DataError",
                "message": "[{{statusCode}}] {{body.error.message}}"
            },
            "500": {
                "type": "ConnectionError",
                "message": "[{{statusCode}}] {{body.error.message}}"
            }
        }
    }
}

HTTP 2** and 3** error handling

Some APIs return an error with a HTTP 200 status code with a flag/error in the body. For this scenario, there exists the Valid directive, which tells whether the response should be processed or error should be thrown.

See the Valid for more details.

Note: It is NOT possible to use specific HTTP code 200-399 error directives without the using Valid directive.

Custom error handling based on status codes

You are also able to further customize what error message will be shown to the user based on the status code. To do that, just add your status code to the error directive and fill it in as one:

{
    "response": {
        "error": {
            "400": {
                "message": "Your request was invalid"
                // applied on HTTP status code is 400 (generic message ignored in this case)
            },
            "500": {
                "message": "The server was not able to handle your request"
                // applied on HTTP status code is 500 (generic message ignored in this case)
            },

            "message": "Generic error message"
            // applied if not matched the specific HTTP status code
        }
    }
}

Available error types in apps

When handling an error, you can specify the type of the error:

• UnknownError

• RuntimeError (default)

  • Primary error type. Execution is interrupted and rolled back.

• InconsistencyError

• DataError

  • Incoming data is invalid. If incomplete executions are enabled, execution is interrupted and the state is stored. The user is able to repair the data and resume execution.

• RateLimitError

  • Service responded with rate-limit related error. Applies delay to the next execution of a scenario.

• OutOfSpaceError

  • The user is out of space.

• ConnectionError

  • Connection-related problem. Applies delay to the next execution of a scenario.

• InvalidConfigurationError

  • Configuration-related problem. Deactivates the scenario and notifies the user.

• InvalidAccessTokenError

  • Access token-related problem. Deactivates the scenario and notifies the user.

• UnexpectedError

• MaxResultsExceededError

• IncompleteDataError

  • Incoming data is incomplete.

• DuplicateDataError

  • Reports error as warning does not interrupt execution. If incomplete executions are enabled, execution is interrupted and the state is stored. The user is able to repair the data and resume execution.

Example of error handling with type

{
    "response": {
        "error": {
            "type": "DataError", // `RuntimeError` is the default, if type is not specified
            "message": "[{{statusCode}}] {{body.message}}"
        }
    }
}