- Home
- Skills
- Yanko Belov
- Code Craft
- Fail Fast
fail-fast_skill
- TypeScript
6
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill yanko-belov/code-craft --skill fail-fast- SKILL.md7.4 KB
Overview
This skill enforces a fail-fast approach to error handling in TypeScript code. It reminds developers not to swallow exceptions or return default values that hide failures. The goal is to surface errors immediately so they can be handled at appropriate boundaries with full context.
How this skill works
The skill inspects code patterns that silence or mask errors: empty or generic catch blocks, catch blocks that return defaults (null, success=false), silent early returns, and overly defensive null-checks that hide failures. It highlights places to throw specific errors, validate early, assert invariants, and rely on the type system so failures propagate to the API or top-level handlers where they can be logged and converted to user responses.
When to use it
- When you see try/catch blocks returning defaults or swallowing errors
- When defensive null checks are everywhere and bugs hide
- When code returns generic error objects instead of throwing
- When you want clearer stack traces and faster debugging
- When enforcing input validation and invariant assertions
Best practices
- Validate inputs early and throw descriptive ValidationError on bad data
- Assert invariants and fail immediately when they break
- Let underlying operations throw; catch and handle only at boundaries
- Use specific error types (ValidationError, NotFoundError, PaymentError)
- Log rich error context at the boundary then map to user-friendly responses
Example use cases
- Replace catch { return null } with explicit throws and boundary handlers
- Validate API request payloads at the entry point and throw on invalid input
- Stop returning { success: false } from deep business logic; throw instead
- Use TypeScript types to avoid nullable parameters and fail fast on contract violations
- Assert account invariants in financial operations and throw if violated
FAQ
No. Throwing lets you catch errors at the boundary (API layer) where you can log, classify, and return appropriate HTTP responses. It prevents corrupted state and hidden bugs.
When are return-style error objects acceptable?
They are acceptable only if every caller reliably checks and handles both success and failure branches. In practice, unchecked returns lead to silent failures, so prefer throwing unless you enforce exhaustiveness.