Portal Community
Portal / Nodes / Try Block / Examples

Try Block — Examples

Complete try/catch/finally workflow patterns for resilient error handling.

Examples below show the full trio of Try Block + Catch Block + Finally Block nodes as they would appear in a workflow definition. The Try Block node itself has no config — the configuration shown is for the surrounding workflow structure.

01 Wrap External Payment API Call

A payment processing workflow wraps the payment gateway HTTP call in a try block. If the gateway returns an error or times out, the catch block refunds any reserved balance, logs the error, and notifies the finance team. The finally block always records the payment attempt outcome in the audit log. 

// Workflow node sequence (conceptual)
[Validate Order]
  → [Try Block: "try_payment"]
      → [Reserve Balance]
      → [HTTP Request: Payment Gateway]   // may throw HttpRequestException
      → [Update Order Status: paid]
  → [Catch Block: "catch_payment"]
      // Exception variables available:
      // $mem.__exception_type__   => "HttpRequestException"
      // $mem.__exception_message__ => "503 Service Unavailable"
      → [Release Reserved Balance]
      → [Slack Alert: "Payment gateway error: {{ $mem.__exception_message__ }}"]
      → [Set Order Status: payment_failed]
  → [Finally Block: "finally_payment"]
      → [Log Audit: "Payment attempt for order {{ $var.order_id }} — {{ $var.order_status }}"]
[Continue to Order Confirmation]
Outcome: On success, the order is marked as paid and the audit log records success. On payment gateway failure, the balance is released, Finance is alerted via Slack, the order is marked payment_failed, and the audit log records the failure with the exception message. In both cases, execution continues to Order Confirmation.

02 Optional Data Enrichment with Graceful Fallback

During customer onboarding, the workflow attempts to enrich the customer record with data from a third-party company data API. This enrichment is optional — if it fails, default values are used and the workflow continues without interruption. 

// Workflow node sequence (conceptual)
[Create Customer Record]
  → [Try Block: "try_enrichment"]
      → [HTTP Request: Company Data API]   // may throw if company not found
      → [Set Var: enriched_data = API response]
  → [Catch Block: "catch_enrichment"]
      // Enrichment failed — use defaults
      → [Set Var: enriched_data = { industry: "Unknown", size: "Unknown" }]
      → [Log Info: "Enrichment skipped for {{ $var.company_name }}: {{ $mem.__exception_message__ }}"]
  // No Finally Block needed here
[Update Customer Record with enriched_data]
[Send Welcome Email]
Outcome: Whether the enrichment API succeeds or fails, the customer record is updated and the welcome email is sent. Failed enrichments are logged for review but do not block or delay the onboarding flow.

03 Batch Record Processing with Per-Record Error Isolation

A Loop node iterates over a list of records. Each iteration wraps the record processing in a try block, so that a single bad record does not stop the entire batch. Failed records are collected in an error list for a final summary report. 

// Inside each loop iteration:
[Get Current Record]
  → [Try Block: "try_record_processing"]
      → [Validate Record Schema]
      → [Transform Data]
      → [HTTP Request: ERP Import API]
      → [Mark Record: success]
  → [Catch Block: "catch_record_processing"]
      → [Append to $var.failed_records: { id: $var.current_record_id, error: $mem.__exception_message__ }]
      → [Mark Record: failed]
  // No Finally needed — loop moves to next iteration

// After loop exits:
[If $var.failed_records.length > 0]
  → [Send Summary Email: "{{ $var.failed_records.length }} records failed processing. Details: ..."]
Outcome: All records are processed. Failures are isolated per-record, collected, and reported in a summary email after the batch completes. No single bad record interrupts processing of the remaining records.

04 Nested Try Blocks for Multi-Step Operations

A complex provisioning workflow uses nested try blocks: an outer try wraps the entire provisioning flow, and an inner try wraps a specific sub-step (sending a welcome email) that should fail silently without rolling back the entire provisioning. 

// Outer try — catches critical failures
[Try Block: "try_provisioning"]
    → [Create AD User Account]       // critical — outer catch handles failure
    → [Assign Licenses]              // critical
    → [Try Block: "try_welcome_email"]   // inner try — non-critical
          → [Send Welcome Email]         // optional — fail silently
      → [Catch Block: "catch_welcome_email"]
          → [Log: "Welcome email failed — {{ $mem.__exception_message__ }}"]
    → [Update HR System: account_created]
→ [Catch Block: "catch_provisioning"]
    → [Rollback: Delete AD User]
    → [Alert IT Team: "Provisioning failed for {{ $var.employee_name }}"]
→ [Finally Block: "finally_provisioning"]
    → [Log Audit: "Provisioning attempt for {{ $var.employee_name }}"]
Outcome: AD account creation and license assignment failures are caught by the outer catch block, triggering rollback. Welcome email failures are caught by the inner catch block and logged without affecting the main provisioning flow. The audit log always records the attempt.