Skip to content

Martini Workflows Try Catch Node

Overview

The Try Catch Node provides exception handling and error management for your Martini workflows, similar to try-catch and try-catch-finally blocks in Java and other programming languages. It enables fail-safe execution and proper error handling, ensuring your workflows can gracefully handle unexpected errors without crashing.

What You Will Learn

  • How to add Try Catch Nodes to workflows for exception handling
  • How to configure try, catch, and finally branches for comprehensive error management
  • Key properties and troubleshooting techniques for robust workflow design

When To Use This

Use this when you need to:

  • Handle potential exceptions in workflow logic that might fail
  • Provide fallback behavior when operations encounter errors
  • Ensure critical cleanup operations execute regardless of success or failure
  • Create fault-tolerant workflows that continue running despite individual step failures
  • Implement retry logic or alternative execution paths for unreliable operations

Prerequisites

Adding Try Catch Nodes to Workflows

Add a Try Catch Node to provide exception handling for risky operations in your workflow.

  1. Navigate to your Martini Package and open your workflow in the Workflow Designer.
  2. Click the Add Node button in the toolbar.
  3. Select Try/Catch from the node types menu.
  4. Drag the Try/Catch Node to your desired position in the workflow canvas.

Expected result: The Try/Catch Node appears with three edge handles () labeled try, catch, and finally, ready for connecting to other workflow nodes.

Try Catch Node Edge Types

The Try Catch Node operates through three distinct edge types that define different execution paths for your workflow logic. Each edge serves a specific purpose in exception handling and workflow control flow. You will initially see these edges as edge handles (triangle icons ) on the right side of the Try Catch Node. You will need to create edges from these handles to connect them to other workflow nodes.

Try Edge - Primary Execution Path

The try edge connects to nodes containing your main workflow logic that might encounter exceptions or failures.

  • Purpose: Execute primary business logic under exception monitoring
  • Connection: Required - must connect to at least one node
  • Execution Order: Always executes first when the Try Catch Node runs
  • Exception Behavior: Any uncaught exceptions automatically transfer execution to the catch edge

When to Use:

  • API calls that might timeout or fail
  • Database operations which failure need to be handled
  • File operations that might fail due to permissions or missing files
  • Any risky operations that need error protection

Catch Edge - Exception Handling Path

The catch edge connects to nodes that handle exceptions and errors thrown from the try edge execution.

  • Purpose: Provide graceful error handling and recovery logic
  • Connection: Required - must connect to at least one node for proper error handling
  • Execution Order: Executes only when exceptions occur in try edge nodes
  • Exception Behavior: Can access exception details for logging, user notifications, or alternative processing

Nodes connected to the catch edge will have access to the $exception model property which contains detailed error information about the exception that occurred.

$exception Model Properties

The $exception model provides access to comprehensive error details through the following properties:

Property Type Description
message String Human-readable error message describing what went wrong
type String Exception type classification
className String Java class name of the exception that was thrown
realException Object Reference to the actual underlying exception object
stacktrace ModelArray Array of stack trace entries showing execution path

Stacktrace Array Properties

Each entry in the stacktrace array contains the following workflow execution details:

Property Type Description
workflowName String Name of the workflow where the error occurred
nodeName String Display name of the specific node that threw the exception
nodeType String Type classification of the node
nodeId String Unique identifier of the node within the workflow

When to Use:

  • Log error details for debugging and monitoring
  • Send user notifications about operation failures
  • Implement retry logic or fallback operations
  • Provide default responses when primary operations fail

From here you can use Map Nodes to map exception values using mapping lines or set expressions to wherever you need in the workflow. For detailed guidance on data transformation techniques, see the Data Mapping guide.

Finally Edge - Cleanup Operations Path

The finally edge connects to nodes that perform cleanup operations regardless of success or failure.

  • Purpose: Ensure critical cleanup operations always execute
  • Connection: Optional - only needed when cleanup operations are required
  • Execution Order: Always executes last, after both try and catch processing completes
  • Exception Behavior: Executes regardless of whether exceptions occurred in try or catch edges

When to Use:

  • Ensure to execute logic whether the try failed or succeeded
  • Continue workflow execution normally even if try failed
  • Update status tracking or audit logs
  • Clean up temporary files or cache entries

Implementing Try Catch and Finally Branches in Workflows

Configure the three execution branches by creating edges from the Try Catch Node to your workflow logic nodes.

Configuring Try Branch Logic

Connect nodes containing your primary workflow operations to the try edge handle.

  1. Click and drag from the try edge handle () on the Try Catch Node.
  2. Connect to the first node in your primary execution sequence.
  3. Add subsequent nodes that represent the main workflow logic.
  4. Ensure all risky operations (API calls, file operations, etc.) are included in this branch.

Example Configuration: 

1
Try Catch Node → [try edge] → HTTP.http() Function Node to send a request → Map Node → Database Insert Node
Expected result: Primary workflow logic executes under exception handling protection.

Configuring Catch Branch Logic

Connect error handling and recovery nodes to the catch edge handle.

  1. Click and drag from the catch edge handle () on the Try Catch Node.
  2. Connect to nodes that handle error conditions (logging, notifications, alternative processing).
  3. Include any retry logic or fallback operations in this branch.
  4. Consider adding user notification or error reporting nodes.

Example Configuration: 

1
Try Catch Node → [catch edge] → Log Error Node → Send Alert Node → Default Response Node

Expected result: Error conditions are gracefully handled with appropriate responses and logging.

Configuring Finally Branch Logic (Optional)

Connect cleanup and finalization nodes to the finally edge handle when needed.

  1. Click and drag from the finally edge handle () on the Try Catch Node.
  2. Connect to nodes that perform cleanup operations (close connections, release resources).
  3. Include any operations that must execute regardless of success or failure.
  4. Avoid operations that might themselves throw exceptions in finally blocks.

Example Configuration: 

1
Try Catch Node → [finally edge] → Close Connection Node → Update Status Node → Cleanup Temp Files Node

Expected result: Essential cleanup operations execute regardless of try/catch outcomes.

Try Catch Node Benefits and Use Cases

The Try Catch Node transforms unreliable workflow operations into robust, production-ready automation by providing comprehensive exception management.

Why It Matters:

  • Production Reliability: Prevents single node failures from breaking entire workflows
  • Business Continuity: Maintains service availability even when individual operations fail
  • Operational Visibility: Captures detailed error information for monitoring and debugging
  • Resource Protection: Guarantees cleanup operations execute to prevent resource leaks

Strategic Use Cases:

  • Integration Workflows: Handle unreliable external APIs and services gracefully
  • Data Processing Pipelines: Continue batch operations despite individual record failures
  • Scheduled Automation: Ensure recurring tasks complete successfully or fail with proper notification
  • User-Facing Workflows: Provide consistent responses to end users regardless of backend issues

Troubleshooting

Problem Detection Cause Fix
Warning icon on Try Catch Node Node displays warning indicator No nodes connected to try and catch edges Create edges connecting nodes to both try and catch handles
Exceptions not being caught Errors propagate beyond Try Catch Node Catch edge not connected to handling nodes Connect appropriate error handling nodes to catch edge
Finally block not executing Cleanup operations skipped Finally edge not properly connected Verify finally edge connection and node sequence
Infinite error loops Workflow becomes unresponsive Exception thrown in catch block without handling Add exception handling within catch block or simplify catch logic