> This page is for Tools. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Try Catch and Raise Error # Overview The **Raise** expression gives you a sharp tool to flag errors explicitly and stop execution of compound actions. The **Try Catch** expression complements it by attempting risky code and rerouting on failure. #### Raise This expression triggers an immediate exit, much like throwing an exception in code, but with a stored output for traceability. Always set an `output_key` to capture the error object (status, details), and add a message for clarity in logs or chats. #### Try Catch The **`try_catch`** expression allows for the execution of a compound action expression with an error handling mechanism. If the **`try`** block encounters an error, the **`catch`** block is executed, allowing for graceful error handling and recovery. This is particularly useful for managing errors in compound actions where certain actions might fail under known or unknown conditions. | Feature | Raise Error | Try Catch | | :------------------- | :------------------------------------------- | :---------------------------- | | **Primary Role** | Intentional failure trigger | Failure containment and route | | **Best Paired With** | Conditionals like `switch` or `catch` blocks | Unreliable actions | ## Error Handling Limitations **Important:** The `try_catch` expression does **not** expose the actual API error details (like error messages or response bodies) to the `catch` block. However, you can filter catch blocks by HTTP status codes using `on_status_code`, which allows you to use status codes as identifiers for different error scenarios. For example: * Catch `404` errors for "not found" scenarios * Catch `500` errors for server issues * Catch `403` errors for permission problems This approach lets you create targeted recovery logic based on the type of failure, even without access to the detailed error information. ### Supported Status Codes Use numeric HTTP status codes in `on_status_code`. The field supports these error status codes: * Client errors: `400`, `401`, `403`, `404`, `405`, `408`, `409`, `410`, `422`, and `429` * Server errors: `500`, `501`, `502`, `503`, and `504` If you omit `on_status_code`, the `catch` block handles any error. The field does not match error codes in response bodies or WebSocket close codes. # Low-Code Editor Combine the Try Catch and Raise steps for graceful error handling ![](https://files.readme.io/e7916295995d737a69a0eb5e832cd48858fd53769ea992c06e394bdd3c6fd052-CleanShot_2025-09-17_at_09.49.46.png) 1. **Set Up Your Steps**: Accordingly set up steps within your Try and Catch blocks ![](https://files.readme.io/c47c97a6d87bb7e5fdfab4a4b5fbfaef79ed994c7e1a2bfd61c550ce866ff4e0-CleanShot_2025-09-17_at_09.50.06.png) 2. **Filter by Status Code**: For common errors and expected issues, set the catch block to trigger on specific status codes. ![](https://files.readme.io/c07ef04d1e856a4cb06c67aba36def3322bb209fd7d892ae3d93672b7bb3ec50-CleanShot_2025-09-17_at_09.51.11.png) 3. **Add Graceful Exit**: Add a Raise step to provide an error message and gracefully end the execution of the flow. # Syntax Reference #### Raise Schema ```yaml raise: output_key: ERROR_VAR* # any: Holds error details (e.g., {status: E403, message: ...}) message: 'ERROR_MSG' # str: Optional log/chat note ``` | Field | Type | Mandatory | Description | | :----------- | :----- | :-------- | :-------------------------------------------------------------------- | | `output_key` | string | Yes | Error storage for data bank | | `message` | string | No | Mustache expression string, e.g., `"There was an error {{ error }} "` | #### Try Catch Schema ```yaml try_catch: try: steps: # Expressions to attempt - EXPRESSION_1 # e.g., flaky action catch: on_status_code: [404, 500] # Optional steps: # Recovery (no error details available) - EXPRESSION_2 # e.g., notify with static msg ``` | Field | Type | Mandatory | Description | | :--------------------- | :---------- | :-------- | :-------------------------------------------- | | `try.steps` | list\[expr] | Yes | Attempted expressions | | `catch.on_status_code` | list\[int] | No | HTTP error filters. Omit to catch all errors. | | `catch.steps` | list\[expr] | Yes | Recovery expressions | # Practical Examples ## Raise ### Example 1: Permission Gate Halt non-admins ```yaml steps: - switch: cases: - condition: meta_info.user.role != 'admin' steps: - raise: output_key: auth_error message: "Access denied: Admin required" - action: name: perform_admin_task output_key: admin_task_result ``` ## Try Catch ### Example 1: Action Recovery Catch a 404, notify the admin and raise the error ```yaml try_catch: try: steps: - action: action_name: may_fail_action output_key: action_result catch: on_status_code: [404] steps: - action: action_name: notify_admin output_key: admin_alert input_args: message: "API returned 404—standard flake" - raise: output_key: user_error message: "Item not found—try a different query" ``` ### Example 2: General Fallback Log any error and exit ```yaml try_catch: try: steps: - action: action_name: external_call output_key: api_data catch: # Catches all steps: - raise: output_key: service_down message: "Service temporarily down—retry later" ``` ### Example 3: Status Code-Based Recovery Handle different error types using status codes as identifiers ```yaml try_catch: try: steps: - action: action_name: api_call output_key: result catch: on_status_code: [403, 401] steps: - raise: output_key: auth_failure message: "Authentication failed—please check permissions" # Separate catch for server errors try_catch: try: steps: - action: action_name: api_call output_key: result catch: on_status_code: [500, 502, 503] steps: - action: action_name: log_server_error output_key: log_result - raise: output_key: server_error message: "Server temporarily unavailable—retry in a few minutes" ```