error-handling-typed-results

Implements sealed Result and Failure types for exhaustive Dart error handling.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/zakariaf/NearlyStop --skill error-handling-typed-results-zakariaf
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: error-handling-typed-results
Source: https://github.com/zakariaf/NearlyStop/tree/main/.claude/skills/error-handling-typed-results
Command: npx skills add https://github.com/zakariaf/NearlyStop --skill error-handling-typed-results-zakariaf

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Flutter and Dart apps often leak low-level exceptions into the UI, swallow errors silently, or lose user-entered data on crashes and mistaken deletes. This Skill enforces a typed-error architecture where recoverable failures are sealed Result values switched on exhaustively, only bugs throw into a global error net, and transactions, autosave drafts, and soft-delete with Undo protect hand-entered data. ## Core Features & Use Cases - Typed Result/Failure spine: Hand-rolled zero-dependency sealed Result<T, F> with one sealed Failure family per boundary, carrying stable codes and typed params instead of localized strings. - Convert-at-boundary discipline: Narrow on-clause catches that log the original error and stack before returning a typed Failure, plus Isolate.run error re-wrapping and exhaustive switches with no default case. - Never-lose-data layer: One transaction per multi-table mutation, debounced autosave drafts, and optimistic soft-delete with Trash and SnackBar Undo behind a single shared filter. - CI guard scripts: check-swallowed-catch.sh and check-softdelete-parity.sh grep for banned catch patterns and analytics queries that bypass the active-only filter. - Use Case: When writing a repository method that calls SQLite, wrap the call once, catch SqliteException narrowly, log it, and return Err(ConstraintViolated(field)) so the Notifier switches every failure case and the UI localizes from the stable code. ## Quick Start Ask the AI to apply the error-handling-typed-results skill when writing a new repository boundary or reviewing a try/catch so failures become sealed Result values with exhaustive switches.

Frequently Asked Questions about error-handling-typed-results

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a sealed Result type in Dart 3?

Define a sealed Result<T, F extends Failure> class with final Ok and Err subclasses, then add fold and map via an extension. Keep it in a Flutter-free core layer so pure logic and repositories share one vocabulary, and switch on it exhaustively with no default case.

Should I use result_dart or hand-roll a Result type in Flutter?

Either adopt result_dart wholesale across the codebase for ready-made flatMap, mapError, and AsyncResult, or hand-roll a zero-dependency sealed Result. Never mix both approaches, and avoid a generic Result whose error arm is Object because it defeats exhaustive switching.

Why should Failure classes carry codes instead of message strings?

A baked-in user-facing string breaks translation, RTL mirroring, and numeral rendering. Each Failure subtype carries a stable localization-key-like code plus typed params, and the presentation layer maps the code to a localized message at the edge.

Do Isolate.run errors reach FlutterError.onError?

No, errors thrown inside Isolate.run or compute do not hit FlutterError.onError. Catch them at the call site where you await the isolate, log the error and stack, and re-wrap them as a typed Result so they do not propagate opaquely.

When should I use runZonedGuarded in a Flutter app?

Default to no runZonedGuarded; FlutterError.onError plus PlatformDispatcher.instance.onError cover Flutter's error surfaces. Add a zone only when a crash-reporting SDK like Sentry or Crashlytics requires one for its own initialization.

How do I prevent soft-deleted rows from polluting analytics queries?

Route every read through one shared filter, such as an orders_active view or an activeOnly query builder, so lists, rollups, and charts all exclude is_deleted rows. The check-softdelete-parity.sh script greps analytics code for base-table reads that bypass the filter.