fp-errors_skill
2
GitHub Stars
1
Bundled Files
3 weeks ago
Catalog Refreshed
2 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 veilstart where the catalogue uses aiagentskills.
npx veilstart add skill whatiskadudoing/fp-ts-skills --skill fp-errors- SKILL.md21.7 KB
Overview
This skill teaches practical error handling with fp-ts so you stop throwing everywhere and start handling errors as values. It focuses on Either and TaskEither patterns that make failures visible in types, simplify async flows, and let you collect or retry errors predictably. No academic jargon — just patterns you can apply in Node, React, and TypeScript codebases.
How this skill works
The skill shows how to replace thrown exceptions with Either<E, A> for sync code and TaskEither<E, A> for async operations. It explains common utilities: tryCatch/tryCatchK, chain/chainW, getApplicativeValidation for accumulating errors, and techniques to convert from nullable values, promises, or throwing libraries. Examples include sequential and parallel pipelines, retries with backoff, and field-aware form validation.
When to use it
- When functions currently throw exceptions and callers cannot see failure cases
- When you need predictable, typed failure handling across sync and async boundaries
- When you want to collect multiple validation errors (e.g., form validation)
- When composing multiple async operations that may fail and you want clear error flow
- When you need retries, fallbacks, or to run tasks in parallel with explicit error handling
Best practices
- Return Either/TaskEither at boundaries and convert throwing/nullable code when entering your domain
- Prefer chain/chainW to compose operations; use Do notation for readable pipelines with intermediate values
- Use getApplicativeValidation plus NonEmptyArray to accumulate form or validation errors
- Keep TaskEither lazy; only execute when required and fold to handle both cases at the edge
- Wrap external libraries with tryCatchK or small adapters so your core code stays pure and typed
Example use cases
- Replace try/catch spaghetti in order processing by returning Either from each step and chaining them
- Validate complex forms and surface all field errors using applicative validation and NonEmptyArray
- Build a dashboard loader that fetches several resources in parallel with TaskEither.ApplyPar and returns a single typed failure
- Implement retry with exponential backoff for flaky network calls using TaskEither plus Task utilities
- Provide cache-then-API fallback pipelines where cache failure falls back to API and finally to a default value
FAQ
No. Start at boundaries: convert external I/O, parsing, and API layers to Either/TaskEither, and gradually propagate typed errors inward.
How do I handle different error types when chaining?
Use chainW to widen the error union or design a common error shape. For validation accumulation use getApplicativeValidation with a semigroup for errors.