hashintel/hash · Archived

handling-rust-errors

HASH error handling patterns using error-stack crate. Use when working with Result types, Report types, defining custom errors, propagating errors with change_context, adding context with attach, implementing Error trait, or documenting error conditions in Rust code.

First seen Mar 24, 2026

Installation

$ npx skills add hashintel/hash --skill handling-rust-errors

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from hashintel/hash · top by installs.

npx skills add hashintel/hash

Browse all from hashintel/hash

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 1.7K
License LICENSE.md
Default branch main
Open issues 12
Status Archived

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseAGPL-3.0
More metadata
triggers
{"type":"domain","enforcement":"suggest","priority":"high","keywords":["error","Result","Report","error-stack","change_context","attach","ResultExt"],"intent-patterns":["\\b(handle|create|define|propagate|convert)\\b.*?\\berror\\b","\\bReport<.*>\\b"]}

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,128 B
  • docs SUMMARY.md 295 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 4 installs

SKILL.md

Rust Error-Stack Patterns

HASH-specific error handling patterns using the error-stack crate for consistent, debuggable error handling across the Rust codebase.

Core Principles

HASH uses error-stack exclusively for error handling:

✅ DO:

  • Use Report<MyError> for all error types
  • Use concrete error types: Report<MyError>
  • Import Error from core::error:: (not std::error::)
  • Import ResultExt as _ for trait methods

❌ DON'T:

  • Use anyhow or eyre crates
  • Use Box<dyn Error> (except in tests/prototyping)
  • Use Report<Box<dyn Error>>
  • Use thiserror (use derive_more instead)

HashQL Compiler Exception

HashQL compiler code uses a different error handling approach.

Code in libs/@local/hashql/* uses the hashql-diagnostics crate instead of error-stack. This is because compiler errors require rich formatting capabilities:

  • Source spans pointing to exact code locations
  • Multiple labeled regions within the same diagnostic
  • Fix suggestions with replacement text
  • Severity levels (error, warning, hint)

Which approach to use:

Location Error Handling
libs/@local/hashql/* (compiler code) Use hashql-diagnostics → See [writing-hashql-diagnostics](../writing-hashql-diagnostics/SKILL.md) skill
Everywhere else Use error-stack patterns from this skill

Traditional error-stack patterns still apply for HashQL infrastructure code (CLI, file I/O, configuration) that doesn't involve compiler diagnostics.

Quick Start Guide

Choose the reference that matches your current task:

Defining Errors

Use when: Creating new error types or error enums

  • Define error types with derive_more
  • Error enum patterns and variants
  • Implement the Error trait
  • Error type hierarchies

Propagating Errors

Use when: Handling Result types, using ? operator

  • Convert errors with .changecontext() and .changecontext_with()
  • Add context with .attach() and .attach_with()
  • Error conversion patterns

Documenting Errors

Use when: Writing doc comments for fallible functions

  • # Errors section format
  • Link error variants
  • Document runtime errors
  • Test error conditions

Common Quick Patterns

Creating an Error

use error_stack::Report;

return Err(Report::new(MyError::NotFound))
    .attach(format!("ID: {}", id));

Propagating with Context

use error_stack::ResultExt as _;

some_result
    .change_context(MyError::OperationFailed)
    .attach("Additional context")?;

Lazy Context (for expensive operations)

use error_stack::ResultExt as _;

expensive_operation()
    .change_context(MyError::OperationFailed)
    .attach_with(|| format!("Debug info: {:?}", expensive_computation()))?;

References

  • [Defining Errors](references/defining-errors.md) - Creating new error types or error enums
  • [Propagating Errors](references/propagating-errors.md) - Handling Result types, using ? operator
  • [Documenting Errors](references/documenting-errors.md) - Writing doc comments for fallible functions