Validating Inputs

Overview

Professional-grade software never outputs garbage regardless of what it receives. "Garbage in, garbage out" is the mark of sloppy, insecure code.

Core principle: Check all data from external sources. Validate all routine parameters from untrusted sources. Decide consciously how to handle invalid data.

Modern standard: "Garbage in, nothing out" OR "Garbage in, error message out" OR "No garbage allowed in"

Violating the letter of this rule is violating the spirit of defensive programming.

When to Use

Always use when writing functions that receive:

• User input (forms, command-line args, uploaded files)
• External API responses
• Database query results
• File contents
• Network data
• Configuration files
• Any data from outside your direct control

Warning signs you need this:

• Function assumes inputs are valid
• No validation beyond empty/null checks
• No assertions documenting assumptions
• Spec mentions constraints but code doesn't check them
• Silent failures or wrong results with bad data
• Security vulnerabilities (injection, overflow, etc.)
• Functions accept any input without question

Don't skip when:

• "Inputs will always be valid" (they won't)
• "Validation happens elsewhere" (defense in depth - check anyway)
• "It's just internal code" (today's internal is tomorrow's API)
• Under time pressure (validation prevents longer debugging)

The Two-Level Defense

Level 1: Assertions (Should NEVER Happen)

Use for: Conditions that indicate bugs in YOUR code

def calculate_velocity(distance: float, time: float) -> float:
    # Preconditions: These should NEVER be violated if caller is correct
    assert distance >= 0, "distance cannot be negative"
    assert time > 0, "time must be positive"

    result = distance / time

    # Postcondition: Result should be reasonable
    assert result >= 0, f"velocity cannot be negative: {result}"

    return result

Assertions are:

• Executable documentation
• Compiled out in production (typically)
• For catching programmer errors during development
• Should fire = bug in code that needs fixing

Level 2: Error Handling (MIGHT Happen)

Use for: Conditions you expect might occur in production

def calculate_average_score(scores: list[float]) -> float:
    """Calculate average of test scores (must be 0-100)."""

    # Error handling: Validate external data
    if scores is None:
        raise ValueError("scores cannot be None")

    if not scores:
        raise ValueError("Cannot calculate average of empty score list")

    # Validate each score
    for i, score in enumerate(scores):
        if not isinstance(score, (int, float)):
            raise TypeError(f"Score {i} is not a number: {score}")
        if score < 0 or score > 100:
            raise ValueError(f"Score {i} out of range [0-100]: {score}")

    result = sum(scores) / len(scores)

    # Postcondition: Verify result is valid
    assert 0 <= result <= 100, f"Calculated average out of range: {result}"

    return result

Error handling:

• Stays in production code
• Handles expected anomalies gracefully
• Validates external/untrusted data
• Should trigger = need to handle error, not fix code

Quick Reference

…