set -e, errexit, and Its Surprising Edge Cases

1. errexit is a control-flow option, not exception handling

set -e (or set -o errexit) asks Bash to exit when an unhandled simple command or compound command returns non-zero. The phrase “unhandled” is the source of most surprises.

flowchart TD
  C["command returns non-zero"] --> Q{"status is being tested?"}
  Q -->|"yes"| K["continue; caller handles it"]
  Q -->|"no"| E["errexit may terminate shell"]

2. The simplest failure can terminate the script

#!/usr/bin/env bash
set -e

printf 'before\n'
false
printf 'after\n'  # not reached

This is the intuitive case: false returns status 1 and is not part of a condition that expects a non-zero result.

3. Commands tested by if are exempt

set -e

if grep -q '^READY$' status.txt; then
  printf 'ready\n'
else
  printf 'not ready or grep failed\n'
fi

printf 'script continues\n'

Bash assumes a command in an if condition is being intentionally tested, so errexit does not terminate the shell merely because the condition is false.

4. && and || lists also change errexit behavior

set -e

check_config && deploy
check_optional || printf 'optional check failed\n' >&2

Commands whose status controls && or || are part of explicit control flow. Do not assume every non-zero status inside these lists aborts the shell.

5. while and until conditions expect non-zero statuses

set -e

attempt=0
while (( attempt < 3 )); do
  ((attempt += 1))
  if probe_service; then
    break
  fi
  sleep 1
done

Loop conditions are another grammar context where non-zero status is expected and therefore does not behave like an unhandled failure.

6. Functions inherit the calling context

set -e

do_work() {
  false
  printf 'function continued\n'
}

if do_work; then
  printf 'reported success\n'
fi

7. Subshell and command-substitution behavior needs testing

set -e

(
  printf 'subshell start\n'
  false
  printf 'subshell after failure\n'
)

Option inheritance and command-substitution behavior can differ by Bash version and settings such as inherit_errexit. Do not base production correctness on assumptions you have not tested on supported Bash versions.

8. Arithmetic commands can return non-zero for ordinary values

set -e

count=0
# This can return status 1 because the arithmetic result is 0:
((count++))

printf 'count=%d\n' "$count"

9. Expected failure should be written as expected control flow

if ! validate_config "$file"; then
  printf 'invalid config: %s\n' "$file" >&2
  exit 65
fi

The point is not to “defeat” set -e; it is to make expected non-zero statuses visible in the program structure.

10. Capture status around operations whose failure needs explanation

if deploy_service "$service"; then
  printf 'deploy succeeded\n'
else
  status=$?
  printf 'deploy failed service=%s status=%d\n' \
    "$service" "$status" >&2
  exit "$status"
fi

Explicit branches produce better diagnostics than relying on a shell-wide implicit exit.

11. Hands-on lab: observe errexit contexts

mkdir -p "$HOME/devops-academy/bash/chapter11/lesson01"
cd "$HOME/devops-academy/bash/chapter11/lesson01"

cat > demo.sh <<'EOF'
#!/usr/bin/env bash
set -e

printf '1: ordinary success\n'
true

printf '2: failure inside if condition\n'
if false; then
  printf 'unexpected true\n'
else
  printf 'condition was false; script continues\n'
fi

printf '3: handled failure\n'
if bash -c 'exit 7'; then
  :
else
  status=$?
  printf 'captured status=%d\n' "$status"
fi

printf '4: done\n'
EOF

bash demo.sh

12. Knowledge check

13. Summary

set -e is useful as a guardrail, not as a complete error-handling model. Understand its grammar-dependent exemptions, make expected failures explicit, and use direct status checks where diagnostics or recovery matter.

14. Further reading

• GNU Bash Reference Manual — The Set Builtin and errexit.
• GNU Bash Reference Manual — Bourne Shell Builtins.
• BashFAQ/105 — discussion of set -e pitfalls.
• ShellCheck documentation on errexit-related patterns.