/docs/decisions/0003-reject-raise-without-from-hook.md

ADR-0003: Reject universal raise-without-from enforcement

Date: 2026-03-28 Status: Accepted

Context

PR #3225 proposed a pre-commit hook (check-raise-without-from) to enforce raise X(...) from e inside all except blocks, citing PEP 3134 (explicit exception chaining). The hook would flag any raise NewException(...) inside an except handler that omits the from clause.

The conflict with existing security hooks

The codebase already enforces exception sanitization to prevent PII leakage through three mechanisms:

1. check-sensitive-logging.py blocks exception variables in logger.warning/error/critical() calls and forbids exc_info=True on production log levels. Only logger.exception() and logger.debug(..., exc_info=True) are permitted.

2. fix-exception-logging.py auto-removes exception variable references from f-strings and exc_info=True from non-debug logs.

3. Intentional chain-breaking pattern used across the codebase: catch a broad exception, log full details with logger.exception(), then raise a sanitized application exception without from e:

   except Exception as e:
       logger.exception("Error getting news feed")    # full details logged
       raise NewsFeedGenerationException(str(e), ...)  # no "from e"
   

   This pattern appears in news/api.py, notifications/service.py, utilities/es_utils.py, and others. Flask error handlers then return only error_code and message to the client — never stack traces.

Why raise X from e is harmful here

raise X from e preserves the full original exception chain at the Python runtime level. Even if logs are sanitized, the chain propagates to:

• Error tracking services (Sentry, DataDog) that capture __cause__
• Any downstream handler that logs with exc_info=True
• Test output and development tooling that prints full tracebacks

If the original exception contains PII (SQL errors with user data, API responses with auth tokens, file paths with usernames), preserving the chain defeats the sanitization strategy.

When from e IS appropriate

Explicit chaining is valuable in infrastructure code where:

• The original exception contains no user data (e.g., config parsing errors)
• Both exceptions will be caught and handled before reaching any boundary
• Debugging requires understanding the root cause chain

The seven existing from e usages in the codebase (mcp/client.py, config/llm_config.py, security/path_validator.py, exporters/) follow this pattern correctly.

Decision

Do not add a universal raise-without-from enforcement hook. The existing pattern of intentional chain-breaking for PII protection takes precedence over PEP 3134 compliance.

Developers should use their judgment:

• Use raise X from e when the original exception is safe to propagate (no user data, internal infrastructure errors)
• Use raise X from None when you want to explicitly suppress the chain and document the intent
• Omit from when wrapping user-facing exceptions to sanitize error details (the current default pattern)

Consequences

• The allowlisted files in the rejected PR do not need remediation
• Exception chain decisions remain a code review concern, not an automated enforcement
• The existing check-sensitive-logging and fix-exception-logging hooks remain the primary defense against PII leakage through exceptions
• raise X from None is available for cases where developers want to explicitly document chain suppression, but is not required