How do I install the Python Error Handling skill?

Run npx skillmds@latest add amey-thakur/python-error-handling in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Python Error Handling safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Python Error Handling?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Python Error Handling free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Python Error Handling?

Amey-Thakur (@amey-thakur) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Python Error Handling by amey-thakur

Name: Python Error Handling
Author: Amey-Thakur

Python Error Handling

Design exception hierarchies, catch narrowly, and preserve error context so failures stay diagnosable. Use when structuring errors in a Python library or application, or cleaning up broad except blocks.

Amey-Thakur cd56ca9 2.4 KB Updated Sep 17, 2026

File contents

Python error handling

An exception is part of your API. Callers can only handle what you raise deliberately and document; everything else is a bug report.

Method

Define one root exception per package. class AppError(Exception), then a small tree of specific subclasses (ConfigError, RetryableError). Callers catch your root to shield themselves from your internals, or a leaf to handle one case. Never raise bare Exception.
Catch the narrowest type that you can act on. except OSError when you handle missing files; never except Exception except at a top-level boundary that logs and exits or returns a 500. An unhandled exception with a clean traceback beats a swallowed one every time.
Preserve context when translating. Re-raise with raise ConfigError("bad port") from exc so the original traceback chains. from None is only for deliberately hiding an implementation detail, and deserves a comment.
Keep try blocks one line where possible. Wrap only the statement that can fail, not the whole function; a broad block hides which call raised and catches errors you never meant to.
Put cleanup in finally or a context manager. Resource release must not depend on success. If you write the same try/finally twice, write a contextlib.contextmanager instead.
Use ExceptionGroup for concurrent failures. On 3.11+, TaskGroup and your own fan-out code raise groups; handle them with except* per type rather than flattening to the first error and losing the rest.
Decide retryable vs fatal at raise time. Encode it in the type (RetryableError) or an attribute, not by string-matching messages at the call site.

Boundaries

Exceptions are for exceptional paths. An expected absent value is a None return or a sentinel, not a raise; parsing user input that often fails may deserve a result object instead.
Do not log and re-raise at every level; one log at the boundary where the exception is finally handled, or you flood logs with duplicates.
Never use exceptions for flow control across module boundaries; that is an API contract disguised as an accident.

---name: python-error-handlingdescription: Design exception hierarchies, catch narrowly, and preserve error context so failures stay diagnosable. Use when structuring errors in a Python library or application, or cleaning up broad except blocks.---# Python error handlingAn exception is part of your API. Callers can only handle what you raisedeliberately and document; everything else is a bug report.## Method1. **Define one root exception per package.** `class AppError(Exception)`, then a small tree of specific subclasses (`ConfigError`, `RetryableError`). Callers catch your root to shield themselves from your internals, or a leaf to handle one case. Never raise bare `Exception`.2. **Catch the narrowest type that you can act on.** `except OSError` when you handle missing files; never `except Exception` except at a top-level boundary that logs and exits or returns a 500. An unhandled exception with a clean traceback beats a swallowed one every time.3. **Preserve context when translating.** Re-raise with `raise ConfigError("bad port") from exc` so the original traceback chains. `from None` is only for deliberately hiding an implementation detail, and deserves a comment.4. **Keep try blocks one line where possible.** Wrap only the statement that can fail, not the whole function; a broad block hides which call raised and catches errors you never meant to.5. **Put cleanup in finally or a context manager.** Resource release must not depend on success. If you write the same try/finally twice, write a `contextlib.contextmanager` instead.6. **Use ExceptionGroup for concurrent failures.** On 3.11+, TaskGroup and your own fan-out code raise groups; handle them with `except*` per type rather than flattening to the first error and losing the rest.7. **Decide retryable vs fatal at raise time.** Encode it in the type (`RetryableError`) or an attribute, not by string-matching messages at the call site.## Boundaries- Exceptions are for exceptional paths. An expected absent value is a `None` return or a sentinel, not a raise; parsing user input that often fails may deserve a result object instead.- Do not log and re-raise at every level; one log at the boundary where the exception is finally handled, or you flood logs with duplicates.- Never use exceptions for flow control across module boundaries; that is an API contract disguised as an accident.

Frequently asked questions