PADFoundationerror-handlingtry-catchresiliencefoundationblockexception
Error Handler Wrapper
A structured BLOCK/ON ERROR pattern that catches exceptions, logs the error details, increments the error counter, and optionally rethrows. Drop this around any risky action group - file I/O, web calls, Excel operations - for consistent error handling across your flow.
0 copies
Section 1: Configure Error Context
Section 2: Protected Block with Error Handling
Usage Notes
- Replace
REPLACE_WITH_STEP_NAMEwith a descriptive label for the action group being protected (e.g.,$'''Excel File Save''') - Place all risky actions inside the
BLOCK ErrorHandlerwhere the comment marks the insertion point - The
ON BLOCK ERROR REPEAT 1 TIMES WAIT 2line provides one automatic retry with a 2-second delay before the error handler fires - Set
boolRethrowtoTrueif you want the error to propagate up to the parent flow after logging; leave asFalseto swallow the error and continue strErrorMessagecaptures a formatted error string with the step name prefix — use it for logging or notificationnumErrorCountincrements on each error — check this counter at flow end to determine overall success/failurestrErrorTimestamprecords when the error occurred for audit trail purposes- Wrap each major section of your flow (file operations, API calls, Excel work) in its own Error Handler Wrapper with a unique
strStepName - Combine with Retry With Backoff for nested resilience: retry inside the block, then catch with this wrapper if all retries fail
Requirements
- No external dependencies — uses only built-in PAD block, error handling, and DateTime actions
LastErroris a built-in PAD object automatically available inside ON BLOCK ERROR handlersnumErrorCountshould be initialized by Variable Bootstrap if used across the full flow; Section 1 provides a local fallback- DateTime action must be available for timestamp capture (included in all PAD versions)
- For rethrow behavior, the parent flow or calling subflow must have its own error handler to catch the propagated error