Try Except

> Project: honnibal/claude-skills. "Claude skills I'm experimenting with. Please review carefully before use." > > License: MIT License. Full license text is in [LICENSE](LICENSE) alongside this file. > > Snapshot: Frozen copy of try-except.md.txt as of 2026-05-22. The maintained version lives upstream and may have evolved since this snapshot.

Interrogate Try/Except Usage

You are now in try/except audit mode. Your job is to read Python source files, find every try/except block, and evaluate whether each one is correctly scoped, catches the right exceptions, and doesn't mask bugs.

The guiding principle: context determines whether try/except or a conditional check is appropriate. Try/except is for external state you cannot control — filesystem, network, concurrent access — where race conditions make precondition checks unreliable. For conditions over local values, use if, in, hasattr, or similar checks instead.

Built-in exceptions like KeyError, AttributeError, TypeError, and IndexError are fire escapes — emergency exits that tell you a bug has occurred. Catching them indiscriminately is stacking old furniture in the fire escape: harmless until a real emergency, then fatal.

Scope

$ARGUMENTS

• If the user names specific files or directories, scope your work to those.
• If no argument is given, work through the Python files in the current project.
• For large codebases, use AskUserQuestion to let the user choose which

modules or packages to start with. Don't try to do everything at once.

Workflow

1. Find all try/except blocks. Grep for try: across the files in scope.

Read each file that contains them.

1. Classify each block. For every try/except, work through the analysis

checklist below. Take notes before proposing any changes — you need to understand what each statement in the try block does and where exceptions might actually come from.

1. Propose changes. For each block that has problems, explain the issue and

show the fix. Group your changes by file. Apply the edits after presenting them.

1. Verify. After editing, run the project's test suite and type checker if

configured. Your changes alter control flow — they can break things. Confirm they don't.

Use TaskCreate to track progress across files when there are more than a handful.

Analysis Checklist

Work through these checks for every try/except block, in order.

1. Is try/except the right mechanism?

Try/except is appropriate in two situations:

A. External state you cannot check in advance. The operation interacts with something outside your process where a precondition check would be unreliable (TOCTOU races) or impossible:

• Filesystem access (open(), path.read_text(), os.stat())
• Network calls (requests.get(), socket.connect(), urllib.urlopen())
• Database operations
• Subprocess execution

B. Functions whose API does validation as parsing. Many functions have no cheap way to check whether the input is valid — the only way to find out is to attempt the operation. The function's exception is its validation API, and try/except is the intended usage:

• json.loads(text) — you can't check whether a string is valid JSON without

parsing it. Catching json.JSONDecodeError is correct.

• datetime.strptime(s, fmt) — you can't check whether a string matches a

date format without parsing it. Catching ValueError is correct.

• int(s) / float(s) on external input — regex validation is fragile and

duplicates the parser's logic. Catching ValueError is correct.

• pydantic.BaseModel.model_validate(data) — the whole point is

validate-by-parsing. Catching ValidationError is correct.

• ipaddress.ip_address(s), uuid.UUID(s), re.compile(pattern) — same

principle: the constructor is the validator.

The key distinction: these functions raise their own domain-specific exceptions (or ValueError as a documented part of their API). This is fundamentally different from catching KeyError on a dict lookup, where the exception is a generic signal that something is missing and could come from anywhere in the call stack.

Even when try/except is the right mechanism, the try block must still be tightly scoped — contain only the parsing/external call, not surrounding logic. The by-catch risk is lower (a json.JSONDecodeError is unlikely to come from unrelated code) but not zero, and a tight block makes the intent clear.

Try/except is not appropriate for conditions over local values where a simple check suffices:

| Instead of catching... | Use this check instead | |----------------------------|---------------------------------| | KeyError on d[key] | if key in d: or d.get(key) | | AttributeError on x.y | if hasattr(x, "y"): or check the type | | IndexError on lst[i] | if i **pipeline.py** — Tightened 3 try/except blocks. > loaddata(): moved validateschema(data) out of the try block (was > exposing its KeyError/TypeError to the except clause). connect(): replaced > except Exception with except ConnectionError. getconfig(): replaced > try/except KeyError with dict.get() — the try block contained a call to > parsevalue()` whose KeyError would have been silently caught.

Call out any blocks where you suspect the broad catch is hiding an existing bug — cases where narrowing the except clause might cause currently-silenced exceptions to surface. These are the most valuable findings. The user needs to know about them before you change the error handling.

Critical Rules

• Read before editing. Never propose changes to try/except blocks you

haven't read in full context. You need to understand what every statement in the block does and what it might raise.

• Trace callees. When a function call appears inside a try block, read that

function to understand what exceptions it can raise. A KeyError from prepare_query() is a bug; a ConnectionError from db.connect() is expected. You can't tell the difference without reading both.

• Don't remove error handling blindly. Narrowing a try/except might cause

exceptions to propagate that were previously caught. This is usually desirable (it stops masking bugs), but it changes behaviour. Flag these cases to the user.

• Preserve intentional broad catches. Top-level entry points, plugin

loaders, and task runners sometimes need except Exception to prevent one failure from crashing the whole system. These are appropriate if they log the exception and are at the boundary of the system. Don't narrow them.

• Use else blocks. When moving code out of a try block, consider whether it

belongs in the else clause (runs only if no exception was raised) rather than after the entire try/except/else structure.

• Run tests after changes. Changes to exception handling alter control flow

and can break things. Always verify.

• Ask when uncertain. If you're unsure whether a broad catch is intentional

or accidental, use AskUserQuestion to ask the user before changing it.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hugobowne
• Source: hugobowne/show-us-your-agent-skills
• License: MIT
• Homepage: https://hugobowne.github.io/show-us-your-agent-skills/

Install and usage instructions live in the source repository linked above.