Signaling Errors: The raise Statement

• Functions sometimes encounter states they cannot handle and must signal failure clearly.
• Using raise triggers an exception, integrates with try...except, and stops execution immediately.
• Prefer exceptions over special return values (None, False) to avoid ambiguous error handling.
• Raising early enforces preconditions and supports the "fail fast" principle.

def process_servers(server_list):
    if not isinstance(server_list, list):
        # return None - BAD Practice, better to raise TypeError Exception
        raise TypeError("Input 'server_list' must be of type list.")

    # GOOD practice - Handle edge cases without raising exception
    if len(server_list) == 0:
        print("There are no servers to process. Exiting...")
        return

    print(f"Processing {len(server_list)} servers.")

# process_servers("abc") # Uncommenting will raise TypeError
process_servers([])
process_servers(["web01", "web02"])

Raising Built-in Exceptions

• Built-in exception classes (e.g., TypeError, ValueError, FileNotFoundError) convey standard error semantics.
• Raise TypeError when the argument’s type is wrong; raise ValueError when its value is out of acceptable range.
• Use exceptions like OSError, ConnectionError, etc., when the built-in meaning matches your context.
• Always include a clear, informative message describing the failure.

def set_deployment_replicas(count):
    """Example: enforce input type and value boundaries with built-in Exceptions."""
    try:
        parsed_count = int(count)
    except (ValueError, TypeError):
        raise TypeError(f"Replica count must be int or convertible to int, got {type(count).__name__}")

    if parsed_count < 0 or parsed_count > 100:
        raise ValueError(f"Replica count must be between 0 and 100")

    print(f"Replicas set to {parsed_count}")

for val in [5, -2, "three", 150, "5", 5.0]:
    try:
        set_deployment_replicas(val)
    except (TypeError, ValueError) as e:
        print(f"Caught error: {e}.")