fp-errors_skill

This skill helps you implement robust error handling with fp-ts by returning errors as values and chaining safely.

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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational