docs(guidelines): add exception handling section to backend Python guide

[saltas888]

Why

The backend Python guidelines had no guidance on exception handling, so broad except Exception / bare except: patterns that swallow programming errors and silence real failures had nothing to point reviewers at.

What changed

• Added an Exception Handling section to dev/guidelines/backend/python.md covering: catch only expected exceptions, name the narrowest type(s), keep the try body small, never silence, and re-raise what you can't handle.
• Included good/bad examples and the one justified case for a broad catch (top-level boundary that logs and re-raises).

Docs-only change — no code, no behavior change.

How to review

Read the new section in dev/guidelines/backend/python.md.

---

Summary by cubic

Add an Exception Handling section to dev/guidelines/backend/python.md to discourage broad catches that hide real failures and set clear review standards. It covers catching only expected exceptions, naming narrow types, keeping try blocks small, never silencing errors, re-raising when unhandled, and includes good/bad examples plus the single justified broad-catch case at top-level boundaries.

^{Written for commit 4f92d02. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

Confidence score: 5/5

• In dev/guidelines/backend/python.md, the exception-handling guidance is slightly inaccurate about except Exception vs bare except:, which could mislead readers into over-restrictive or incorrect style choices; this is documentation-only and low runtime risk, but update the sentence before merging to prevent future confusion.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="dev/guidelines/backend/python.md">

<violation number="1" location="dev/guidelines/backend/python.md:283">
P3: This guideline sentence currently implies that both bare `except:` and `except Exception` swallow `KeyboardInterrupt`/`SystemExit`, but in Python only bare `except:` (or `except BaseException`) does that. Clarifying this distinction would keep the new section accurate and avoid reviewers rejecting `except Exception` for the wrong reason.</violation>
</file>

<sub>Shadow auto-approve: would not auto-approve because issues were found.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: This guideline sentence currently implies that both bare except: and except Exception swallow KeyboardInterrupt/SystemExit, but in Python only bare except: (or except BaseException) does that. Clarifying this distinction would keep the new section accurate and avoid reviewers rejecting except Exception for the wrong reason.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At dev/guidelines/backend/python.md, line 283:

<comment>This guideline sentence currently implies that both bare `except:` and `except Exception` swallow `KeyboardInterrupt`/`SystemExit`, but in Python only bare `except:` (or `except BaseException`) does that. Clarifying this distinction would keep the new section accurate and avoid reviewers rejecting `except Exception` for the wrong reason.</comment>

<file context>
@@ -278,6 +278,42 @@ Exceptions where positional arguments are acceptable:
 
+## Exception Handling
+
+Catch only the exceptions you expect and know how to handle. Do not use bare `except:` or a broad `except Exception` to wrap code you haven't verified can raise something you can recover from — it swallows `KeyboardInterrupt`/`SystemExit` intent, hides bugs (typos, `AttributeError`, misconfiguration) behind the same handler as the error you meant to catch, and makes failures silent.
+
+```python
</file context>

Suggested change

Catch only the exceptions you expect and know how to handle. Do not use bare `except:` or a broad `except Exception` to wrap code you haven't verified can raise something you can recover from — it swallows `KeyboardInterrupt`/`SystemExit` intent, hides bugs (typos, `AttributeError`, misconfiguration) behind the same handler as the error you meant to catch, and makes failures silent.

Catch only the exceptions you expect and know how to handle. Do not use bare `except:` or broad `except Exception` to wrap code you haven't verified can raise something you can recover from: bare `except:` also catches `KeyboardInterrupt`/`SystemExit`, while `except Exception` can still hide programming bugs (typos, `AttributeError`, misconfiguration) behind the same handler as the error you meant to catch and make failures harder to diagnose.

[dgarros]

Looks good, recently we also started using rules in .agents/rules, I could see this one being a rule as well
I think either way works