Try Catch and Raise Error

Learn how to use Try Catch and Raise Error expressions for graceful error handling in Moveworks compound actions. Handle API failures and create custom error responses.

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.

Low-Code Editor

Combine the Try Catch and Raise steps for graceful error handling

Set Up Your Steps: Accordingly set up steps within your Try and Catch blocks

Filter by Status Code: For common errors and expected issues, set the catch block to trigger on specific status codes.

Add Graceful Exit: Add a Raise step to provide an error message and gracefully end the execution of the flow.

Syntax Reference

Raise Schema

1 raise:
2   output_key: ERROR_VAR*  # any: Holds error details (e.g., {status: E403, message: ...})
3   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

1 try_catch:
2   try:
3     steps:  # Expressions to attempt
4       - EXPRESSION_1  # e.g., flaky action
5   catch:
6     on_status_code: [404, 500]  # Optional
7     steps:  # Recovery (no error details available)
8       - EXPRESSION_2  # e.g., notify with static msg

Field	Type	Mandatory	Description
`try.steps`	list[expr]	Yes	Attempted expressions
`catch.on_status_code`	list[str]	No	Error filters; omit for all
`catch.steps`	list[expr]	Yes	Recovery expressions

Practical Examples

Raise

Example 1: Permission Gate

Halt non-admins

1 steps:
2   - switch:
3       cases:
4         - condition: meta_info.user.role != 'admin'
5           steps:
6             - raise:
7                 output_key: auth_error
8                 message: "Access denied: Admin required"
9   - action:
10       name: perform_admin_task
11       output_key: admin_task_result

Try Catch

Example 1: Action Recovery

Catch a 404, notify the admin and raise the error

1 try_catch:
2   try:
3     steps:
4       - action:
5           action_name: may_fail_action
6           output_key: action_result
7   catch:
8     on_status_code: [404]
9     steps:
10       - action:
11           action_name: notify_admin
12           output_key: admin_alert
13           input_args:
14             message: "API returned 404—standard flake"
15       - raise:
16           output_key: user_error
17           message: "Item not found—try a different query"

Example 2: General Fallback

Log any error and exit

1 try_catch:
2   try:
3     steps:
4       - action:
5           action_name: external_call
6           output_key: api_data
7   catch:  # Catches all
8     steps:
9       - raise:
10           output_key: service_down
11           message: "Service temporarily down—retry later"

Example 3: Status Code-Based Recovery

Handle different error types using status codes as identifiers

1 try_catch:
2   try:
3     steps:
4       - action:
5           action_name: api_call
6           output_key: result
7   catch:
8     on_status_code: [403, 401]
9     steps:
10       - raise:
11           output_key: auth_failure
12           message: "Authentication failed—please check permissions"
13 
14 # Separate catch for server errors
15 try_catch:
16   try:
17     steps:
18       - action:
19           action_name: api_call
20           output_key: result
21   catch:
22     on_status_code: [500, 502, 503]
23     steps:
24       - action:
25           action_name: log_server_error
26           output_key: log_result
27       - raise:
28           output_key: server_error
29           message: "Server temporarily unavailable—retry in a few minutes"

1	raise:
2	output_key: ERROR_VAR* # any: Holds error details (e.g., {status: E403, message: ...})
3	message: 'ERROR_MSG' # str: Optional log/chat note

1	try_catch:
2	try:
3	steps: # Expressions to attempt
4	- EXPRESSION_1 # e.g., flaky action
5	catch:
6	on_status_code: [404, 500] # Optional
7	steps: # Recovery (no error details available)
8	- EXPRESSION_2 # e.g., notify with static msg

1	steps:
2	- switch:
3	cases:
4	- condition: meta_info.user.role != 'admin'
5	steps:
6	- raise:
7	output_key: auth_error
8	message: "Access denied: Admin required"
9	- action:
10	name: perform_admin_task
11	output_key: admin_task_result