Why this matters
If a function raises exceptions but doesn't document them, it can be unclear what errors to expect. This makes it harder to use the function safely and handle potential failures correctly.
Identify functions that raise exceptions but do not document them in docstrings. Missing exception documentation makes it difficult to understand failure cases. Suggest adding an `:raises` section in the docstring.
If a function raises exceptions but doesn't document them, it can be unclear what errors to expect. This makes it harder to use the function safely and handle potential failures correctly.
Side-by-side examples engineers can pattern-match during review.
def fetch_data():
if error:
raise ValueError('Invalid data')def fetch_data():
"""
Fetches data from the database.
Raises:
ValueError: If the data is invalid.
"""
if error:
raise ValueError("Invalid data")def fetch_data():
if error:
raise ValueError('Invalid data')def fetch_data():
"""
Fetches data from the database.
Raises:
ValueError: If the data is invalid.
"""
if error:
raise ValueError("Invalid data")From the same buckets as this rule.
For changes that affect architecture, data models, external APIs, security posture, deployment topology, or cost (>10%), create an ADR in docs/adr/ using the standard template (Context, Decision, Consequences) and link the PR and issue IDs.