design_patterns-typed_error_sentinels

Create per-package typed error sentinels with phantom types in Go.

2|Updated Jun 26, 2025
One-click install
npx skills add https://github.com/amarbel-llc/dodder --skill design-patterns-typed-error-sentinels
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design_patterns-typed_error_sentinels
Source: https://github.com/amarbel-llc/dodder/tree/main/.claude/skills/design_patterns-typed_error_sentinels
Command: npx skills add https://github.com/amarbel-llc/dodder --skill design-patterns-typed-error-sentinels

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Errors across packages can collide or be misinterpreted; typed error sentinels provide per-package phantom types to isolate and categorize errors at compile time.

Core Features & Use Cases

  • Define per-package disambiguation types to classify errors at compile time.
  • Create and export sentinels with MakeTypedSentinel or NewWithType, and check origin with IsTyped.
  • Wrap and propagate typed errors with WrapWithType while preserving type information; reuse built-in sentinels like ErrNotFound as needed.

Quick Start

Declare a per-package disambiguation type, create typed sentinels with NewWithType or MakeTypedSentinel, and export a package checker with IsTyped.

Frequently Asked Questions about design_patterns-typed_error_sentinels

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

FAQPage Schema
How do I isolate and disambiguate Go errors across different packages at compile time?

You can isolate Go errors across packages by declaring a per-package disambiguation type and creating typed sentinels with MakeTypedSentinel or NewWithType, which classify errors at compile time using a phantom type parameter pattern.

How do I wrap Go errors while preserving their original package type information?

To wrap Go errors while preserving type information, use the WrapWithType utility. It propagates typed errors across module boundaries and maintains the original phantom type parameter so the error source remains identifiable.

Why do my Go errors collide or get misinterpreted when wrapping them across module boundaries?

Go errors collide when wrapping across module boundaries because standard errors lack source package isolation. Typed sentinels solve this by providing per-package phantom types to isolate and categorize errors at compile time.

Does this typed sentinel approach work for checking specific error types like ErrNotFound?

Yes, the typed sentinel approach supports built-in sentinels like ErrNotFound. You can check an error's origin package using the IsTyped utility, and reuse these built-in sentinels as needed within your Go project.

What is the best way to distinguish errors by their source package in Go without runtime overhead?

The best way to distinguish errors by source package without runtime overhead is using typed sentinels. They implement a phantom type parameter pattern with a DISAMB type to classify and isolate errors at compile time.