Bash Error Handling Patterns Library

What this prompt does

This prompt creates a reusable Bash error-handling library (error_lib.sh) that any script in a [project_type] environment can source. It provides a set_strict_mode function with an option to treat unset variables as warnings for [compatibility_mode] scripts, a trap_handler capturing the failing command, line number, and call stack with [error_context] variables, a retry function with jitter to avoid a thundering herd among [parallel_workers], a subshell-based try/catch, a graceful_degradation function falling back via [fallback_strategy], a structured_error emitting JSON for [log_aggregator], and a test script.

The variables adapt the library to your stack. [error_context] defines which environment variables get attached to every error, [parallel_workers] informs the retry jitter so simultaneous retries don't synchronize, and [log_aggregator] shapes the JSON so it parses cleanly downstream. Centralizing these patterns means each script sources one tested library instead of reimplementing trap handlers and retries inconsistently.

When to use it

• You write many deployment and ops scripts and want consistent error handling
• Trap handlers that capture the failing line and call stack for fast root cause
• Retry-with-jitter for flaky network calls across [parallel_workers]
• Emitting structured JSON errors for ingestion by a log aggregator
• A try/catch pattern in Bash via subshells with access to exit code and stderr
• Graceful degradation that falls back through a defined [fallback_strategy]

Example output

You get an error_lib.sh exposing set_strict_mode, trap_handler, retry <max_attempts> <delay_seconds> <backoff_multiplier> <command>, a try/catch construct, graceful_degradation, and structured_error producing JSON with code, message, timestamp, and [error_context]. A companion test script exercises every function with passing and failing scenarios so you can verify the library before sourcing it elsewhere.

Pro tips

• Source this one library everywhere rather than copy-pasting trap handlers; consistency is the whole point of [project_type] adopting it
• Keep the retry's jitter enabled so [parallel_workers] retrying at once do not synchronize into a thundering herd against a recovering service
• Populate [error_context] with the variables you actually grep for during incidents (environment, version, hostname) so errors are self-explaining
• Shape structured_error JSON to match what [log_aggregator] expects, or the fields will not parse into searchable columns
• Use [compatibility_mode] sparingly — treating unset variables as warnings weakens set -u, so reserve it for legacy scripts that need it
• Run the included test script after any change to the library; an error-handling library that itself has a bug is dangerous everywhere it is sourced
• Have trap_handler capture the line number and call stack, not just the exit code; knowing which command failed turns a vague non-zero exit into an actionable root cause
• Wire graceful_degradation to a real [fallback_strategy] and log which path was taken, so a degraded response is visible in the logs rather than silently masking that the primary path failed