Error Handling and Defensive Programming Questions

Direct answer
Build a structured, JSON-serializable log record from an exception and a context dict using only the standard library, so it can be handed directly to a JSON-based logging pipeline without any custom serialization step, and keep the message field free of anything sensitive by construction (never dumping raw request payloads into it).

Structured elaboration

• Pull the essential fields directly from the exception object (type(exc).__name__, str(exc)) rather than requiring the caller to pass them redundantly, since the caller might forget or get them wrong.
• Accept a context dict for caller-supplied fields (service name, correlation id) that the exception object itself has no way to know.
• Keep short_stack bounded (truncate) so a pathological exception with a huge repr doesn't blow up log line size.

Worked example (executed; all assertions passed, including the JSON-serializability check)

def format_error_log(exc, context):
    return {
        "timestamp": now_iso(),
        "level": "ERROR",
        "service": context.get("service", "unknown"),
        "correlation_id": context.get("correlation_id"),
        "error_type": type(exc).__name__,
        "message": str(exc),
        "short_stack": repr(exc)[:200],
    }

Verified: raising ValueError("bad input: age=-5") and formatting it with {"service": "user-api", "correlation_id": "req-42"} produces a dict that json.dumps() successfully serializes (confirming no non-serializable objects, like a raw exception or a datetime object, leaked into the record) with error_type == "ValueError" and the correlation id correctly threaded through from the context.

Trade-offs and pitfalls
Using str(exc) directly as the message field trusts that whoever RAISED the exception didn't embed sensitive data in its message text; this function can't retroactively sanitize a bad message, so the discipline has to live upstream, at every raise site, not here. Truncating short_stack to 200 characters is a pragmatic default but can cut off the most useful part of a deep stack trace for a complex failure; pair this lightweight per-line record with a separate, fuller stack-trace capture (sent to an error-tracking service, not inline in every structured log line) for genuinely complex failures.

Direct answer
A token-bucket rate limiter tracks a token count that refills continuously at a configured rate up to a maximum burst capacity, and tryAcquire() atomically checks and deducts the requested tokens, allowing a burst up to the bucket's full capacity while enforcing a steady sustained rate over time, implemented thread-safely with a lock (or a compare-and-swap loop) around the refill-and-deduct sequence.

Structured elaboration

• Refill logic: compute elapsed time since the last refill, add elapsed * refill_rate tokens (capped at the bucket's capacity), then check if enough tokens are available for this request; doing the refill calculation LAZILY (only when tryAcquire is called, based on elapsed real time) avoids needing a separate background thread just to periodically top up the bucket.
• Burst vs sustained rate: the bucket's CAPACITY governs how large a burst is allowed at once (a capacity of 5 lets 5 requests through instantly even if none have been made recently); the REFILL RATE governs the sustained long-term throughput once the initial burst is exhausted.
• Concurrency primitives: a single lock around the refill-check-deduct sequence is the simplest correct implementation; under high contention, a compare-and-swap loop on the token count (treating it as an atomic value) can reduce lock contention, at added implementation complexity, following the same simple-lock-first, atomic-primitive-if-profiling-justifies-it trade-off discussed in the LRU-cache survivor.
• Complexity: tryAcquire() is O(1) (a fixed amount of arithmetic plus a lock acquisition), making it cheap enough to call on every request even at high QPS.

Worked example (executed with a fake, controllable clock; all assertions passed)

class TokenBucket:
    def __init__(self, capacity, refill_rate, clock=time.monotonic):
        self.capacity = capacity
        self.refill_rate = refill_rate
        self._tokens = capacity
        self._last = clock()
        self._clock = clock
        self._lock = threading.Lock()

    def _refill(self):
        now = self._clock()
        elapsed = now - self._last
        self._tokens = min(self.capacity, self._tokens + elapsed * self.refill_rate)
        self._last = now

    def try_acquire(self, n=1):
        with self._lock:
            self._refill()
            if self._tokens >= n:
                self._tokens -= n
                return True
            return False

Verified with capacity=5, refill_rate=1.0: exactly 5 consecutive calls succeed immediately (the full burst), a 6th fails (bucket exhausted); after advancing the fake clock by 3 seconds (3 tokens' worth of refill at rate 1.0/s), exactly 3 more calls succeed and a 4th fails, confirming both the burst-capacity ceiling and the sustained refill rate behave as designed.

Trade-offs and pitfalls
A distributed system with MULTIPLE instances each running their own LOCAL token bucket effectively multiplies the aggregate allowed rate by the number of instances (each instance independently allows its own configured burst/rate), which may or may not be the intended behavior; if a GLOBAL rate limit across the whole fleet is required (not per-instance), the bucket state needs to live in a shared store (Redis, with the refill-and-deduct logic implemented as an atomic Lua script or similar), trading the simplicity and low latency of a local, in-memory bucket for a coordinated, fleet-wide guarantee.

Direct answer
Implement timeouts at every layer a request passes through (client SDK, HTTP client, worker-pool task deadline, and a propagated request-level deadline via context/headers), because a timeout set at only one layer leaves the others free to block indefinitely, and a single slow downstream call can otherwise consume resources far past any individual layer's own configured limit.

Structured elaboration

• Client SDK timeout: the outermost caller's own patience limit, often the one users actually experience as latency.
• HTTP client timeout: bounds how long a single network call can take, independent of the SDK's overall patience, since a client might make several HTTP calls per logical operation.
• Worker thread-pool task deadline: bounds how long a worker thread can be occupied processing one task, protecting the POOL itself from being exhausted by one slow task even if that task's own HTTP call has a reasonable timeout (a task can be slow for reasons other than a single network call, like heavy local computation).
• Request-level deadline propagation: a single deadline set at the entry point (an HTTP header, or a context.Context deadline in Go) that's threaded through every downstream call the request makes, so a request that's already spent 4 of its 5-second budget on the first of three downstream calls doesn't naively give the SECOND call another full timeout window; each layer computes its own remaining budget from the shared deadline.

Pseudocode

function handle_request(incoming_deadline):
    deadline = incoming_deadline or (now() + DEFAULT_BUDGET)
    if now() >= deadline:
        return error("deadline already expired")
    ctx = Context(deadline=deadline)
    return process(ctx)

function process(ctx):
    remaining = ctx.deadline - now()
    if remaining <= 0:
        cancel_all_subtasks(ctx)
        return error("deadline exceeded before calling B")
    result_b = http_call(url_b, timeout=remaining, headers={"X-Deadline": ctx.deadline})

    remaining = ctx.deadline - now()
    if remaining <= 0:
        cancel_all_subtasks(ctx)
        return error("deadline exceeded before calling C")
    result_c = http_call(url_c, timeout=remaining, headers={"X-Deadline": ctx.deadline})
    return combine(result_b, result_c)

function cancel_all_subtasks(ctx):
    for task in ctx.in_flight_tasks:
        task.cancel()

The worker thread-pool task deadline is enforced the same way from outside the request path: a background reaper checks each running task's ctx.deadline on a timer and calls task.cancel() on any task whose deadline has already passed, even if that task's own HTTP call has not itself timed out yet, so a deadline expiry always wins over a longer per-call timeout.

Worked example (three-service request timeline)
A request arrives with a 5-second client-set deadline. Service A calls Service B, propagating a deadline of now + remaining budget (say 4.5s after A's own overhead) rather than a fresh 5s; B is slow and takes 4s, leaving A only 0.5s of budget for its own remaining work and for calling Service C; A propagates a deadline to C reflecting that shrunken 0.5s remaining, and C's client correctly times out fast rather than blocking the full 5s it might otherwise assume it has. Without deadline propagation, each hop might independently apply its OWN full timeout, and a three-hop chain with 5s timeouts at each layer could take up to 15s end-to-end even though the original caller only budgeted 5.

Trade-offs and pitfalls
Deadline propagation only works if EVERY service in the chain actually respects the incoming deadline and computes its own downstream calls' timeouts as 'remaining budget', not a fresh full timeout; a single service in the chain that ignores the propagated deadline reintroduces the whole problem for everything downstream of it. Setting the outermost, per-layer timeouts too aggressively short causes false failures under normal-but-slightly-elevated latency; too generous defeats the whole purpose of bounding worst-case latency, so these values need to be set from measured p99 latencies per hop, not guessed.

Direct answer
RAII ties a resource's lifetime to an object's lifetime: the constructor acquires the file descriptor, and the destructor releases it unconditionally, so the resource is freed whether the object goes out of scope normally, via an early return, or during exception unwinding, without the caller ever writing explicit cleanup code.

Structured elaboration

• Move-only semantics: copying a FileHandle would mean two objects both believe they own the same descriptor, and both destructors would call close() on it (a double-close bug); disabling the copy constructor/assignment and providing a move constructor/assignment (which transfers ownership and nulls out the source) makes 'exactly one owner at a time' a compile-time-enforced invariant.
• noexcept on the destructor: as covered in the C++ destructor-during-unwinding question, a throwing destructor risks std::terminate() if it runs during another exception's unwind; close() failures inside the destructor must be caught and logged, never rethrown.
• Leak prevention versus manual open/close: with manual management, EVERY early-return and EVERY exception path in the function needs its own explicit close() call, and it's trivially easy to add a new return path later and forget it; RAII makes that impossible by construction, since the destructor runs on every exit path automatically.

Worked example

class FileHandle {
public:
    explicit FileHandle(const char* path) : fd_(::open(path, O_RDONLY)) {
        if (fd_ < 0) throw std::system_error(errno, std::generic_category(), "open failed");
    }
    ~FileHandle() noexcept {
        if (fd_ >= 0) {
            if (::close(fd_) != 0) {
                // log; never throw from a destructor
            }
        }
    }
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;
    FileHandle(FileHandle&& other) noexcept : fd_(other.fd_) { other.fd_ = -1; }
    FileHandle& operator=(FileHandle&& other) noexcept {
        if (this != &other) {
            if (fd_ >= 0) ::close(fd_);
            fd_ = other.fd_;
            other.fd_ = -1;
        }
        return *this;
    }
    int fd() const { return fd_; }
private:
    int fd_;
};

Any function that creates a FileHandle on the stack gets automatic cleanup on every exit path, including a mid-function throw, with zero explicit close() calls anywhere in the caller's code.

Trade-offs and pitfalls
The move constructor MUST null out the source's fd_ (set it to -1), or the moved-from object's destructor will close a descriptor the new owner still holds; forgetting this is the single most common RAII bug. noexcept on the move operations is not just documentation, it changes real behavior: standard-library containers like std::vector only use the move constructor during a reallocation if it's marked noexcept, silently falling back to the (slower, and here nonexistent, since copy is deleted) copy path otherwise, which for a deleted copy constructor means a compile error rather than silent slowness, but the general pattern is worth knowing for RAII types that DO keep a copy constructor.

Direct answer
A static-analysis rule for broad exception-swallowing pattern-matches the AST for a try block whose except clause either has no type (bare except:), catches the broadest built-in type (except Exception:), and whose handler body is empty (pass), only logs without re-raising, or returns a value that masks the failure (return None) without any logging call in between.

Structured elaboration

• The AST pattern: find every ExceptHandler node; check if its type field is None (bare except) or resolves to Exception/BaseException; then inspect its body for whether it contains ONLY a pass, ONLY a return with no preceding call, or contains no call to a logging function at all.
• False positives to guard against: an except Exception: block that DOES log with full context and then deliberately returns a default value is a legitimate, intentional pattern (not the anti-pattern being targeted); the rule must check for the presence of a logging call in the handler body, not just the exception type being broad, or it will flag correct code and train developers to ignore the rule's output.
• A second false-positive risk: a bare except: inside a context manager's __exit__ or a destructor-equivalent cleanup path is sometimes intentionally broad (see the C++ destructor-safety and Python __exit__ survivors) and swallowing there can be correct; the rule should allow an explicit suppression annotation for these documented cases rather than a blanket ban.
• CI integration: run as a linter step (e.g., a custom flake8/ruff plugin, or a bandit-style AST-walking tool) that fails the build on a NEW violation while allowing a suppression comment (# noqa: swallow-exception) for pre-existing, reviewed cases, following the same incremental-rollout discipline as the broader systematizing-defensive-coding survivor.

Worked example
The rule fires on:

try:
    process(data)
except Exception:
    pass  # flagged: broad catch, no logging, no re-raise

The rule does NOT fire on:

try:
    process(data)
except Exception as e:
    logger.exception("process failed for %s", data_id)
    return None  # OK: logged, so the failure isn't actually invisible

even though both catch Exception broadly, because the second case preserves diagnosability, which is the actual thing the rule cares about, not the exception type breadth in isolation.

Trade-offs and pitfalls
A rule that only checks 'is the except clause empty' is too narrow (misses except Exception: return None with no log call, which is just as dangerous); a rule that flags EVERY except Exception: regardless of body content is too broad and will generate so much noise from legitimate logged-catch-all handlers that developers will disable it. Getting the balance right (broad type AND absence of a logging call, specifically) is what makes the rule worth running in CI rather than becoming background noise everyone learns to ignore.