📋 Overview

waddling-errors provides structured diagnostic codes with a consistent 4-part format:

Error Code Format

[SEVERITY.COMPONENT.PRIMARY.SEQUENCE] → HASH
SEVERITY
Single character: E (Error), W (Warning), C (Critical), B (Blocked), S (Success), K (Completed), I (Info), T (Trace), H (Help)
COMPONENT
Logical/physical component, namespace, module, or location in code (e.g., AUTH, PARSER, DB)
PRIMARY
What the error is related to - category or specific area (e.g., TOKEN, SYNTAX, CONNECTION)
SEQUENCE
3-digit reusable semantic number indicating what happened (e.g., 001=MISSING, 002=MISMATCH, 021=NOTFOUND)
→ HASH
5-character Base62 hash for quick lookup and URL-friendly references

Convention: [EC] → H where EC is the error code and H is the hash

Examples:

[E.AUTH.TOKEN.001] → aB3xY   // Error in Auth component, Token category, MISSING (001)
[W.PARSER.SYNTAX.003] → cD5zA // Warning in Parser, Syntax category, INVALID (003)
[S.BUILD.DONE.999] → eF7gH    // Success in Build, Done category, COMPLETE (999)

This system enables type-safe error handling with compile-time checking, semantic methods for intelligent error handling, and automatic documentation generation with role-based filtering.

✨ Key Features

✅ Type-safe

Define your own component/primary enums with compile-time checking

🔒 Compile-Time Validation

Catch typos, missing components, and invalid sequences at compile time with macro-based validation

📝 Custom Documentation Formats

Generate docs in JSON, HTML, or define your own custom format with role-based filtering

🚀 Zero dependencies

Modular features (doc-gen, hash, serde, emoji, ansi-colors)

🧠 Semantic methods

is_blocking(), is_positive(), priority() for intelligent error handling

📚 Documentation generation

Auto-generate JSON & interactive HTML with role-based filtering

#ī¸âƒŖ Hash codes

Optional 5-character base62 hashes for compact logging

🔧 no_std compatible

Works in embedded and WASM environments

đŸŽ¯ Severity Levels

Nine severity levels with semantic methods:

Severity Code Emoji Priority Blocking Use Case
Error E ❌ 8 Yes Invalid input, logic errors
Blocked B đŸšĢ 7 Yes Deadlock, I/O wait, network down
Critical C đŸ”Ĩ 6 No Data corruption, resource exhaustion
Warning W âš ī¸ 5 No Deprecated API, edge cases
Help H 💡 4 No Helpful suggestion or recommendation
Success S ✅ 3 No Operation succeeded
Completed K âœ”ī¸ 2 No Task/phase finished
Info I â„šī¸ 1 No Events, milestones, status
Trace T 🔍 0 No Execution traces, probes, timing

đŸ”ĸ Sequence Conventions

Semantic sequence numbers provide consistency across all Waddling projects:

001-010: Input/Data

Missing params, type mismatches, invalid formats, duplicates

011-020: State/Lifecycle

Uninitialized, closed, cancelled, timeout issues

021-030: Resource/Storage

Not found, already exists, locked, corrupted data

031-897: Project-specific

Domain-specific errors unique to your project

998-999: Success/Completion

Partial success or full completion indicators

📖 Interactive Documentation Examples

Explore role-based documentation generation with searchable error browsers and interactive query builders:

🚀 Quick Start

Get started with waddling-errors using macros for compile-time safety:

Step 1: Add Dependencies

toml
[dependencies]
waddling-errors = "0.5"
waddling-errors-macros = "0.5"

Step 2: Define Your Error Components

You can use either simple syntax (compact, relaxed validation) or enum wrapper syntax (full validation support):

âš ī¸ Important: Simple syntax below is beautiful but only supports relaxed validation. For full compile-time validation, use the enum wrapper syntax shown after.
Option A: Simple Syntax (Relaxed Validation)
rust
use waddling_errors_macros::{component, primary, sequence, diag};

// Simple syntax - compact but limited validation
component! {
    Auth { value: "AUTH", docs: "Authentication system" }
}

primary! {
    Token { value: "TOKEN", docs: "Token-related errors" }
}

sequence! {
    MISSING(1) { description: "Required field missing" }
}
Option B: Enum Wrapper Syntax (Full Validation) ✅ Recommended
rust
use waddling_errors_macros::{component, primary, sequence, diag};

// Module + Enum wrapper - enables full compile-time validation
mod components {
    use super::*;
    component! {
        pub enum Component {
            Auth { value: "AUTH", docs: "Authentication system" }
        }
    }
}

mod primaries {
    use super::*;
    primary! {
        pub enum Primary {
            Token { value: "TOKEN", docs: "Token-related errors" }
        }
    }
}

mod sequences {
    use super::*;
    sequence! {
        pub MISSING(1) { description: "Required field missing" }
    }
}

use components::Component;
use primaries::Primary;
use sequences::MISSING;
💡 Why enum wrapper? The pub enum wrapper generates validation constants that enable strict(...) mode in diag!. Without it, only relaxed validation is available.

Step 3: Create Error Diagnostics with Validation

Validation mode depends on which syntax you chose in Step 2:

With Simple Syntax (Relaxed Validation)
rust
diag! {
    // No strict validation with simple syntax
    // But still generates constants and docs!
    <json, html, my_custom_format>,

    E.Auth.Token.MISSING: {
        message: "JWT token not found in Authorization header",
        hints: ["Include 'Authorization: Bearer ' header"],
        role: "public",
    }
}

// Use the generated constant
fn authenticate(token: Option<&str>) -> Result<(), Code> {
    token.ok_or(E_AUTH_TOKEN_MISSING)?;
    Ok(())
}
With Enum Wrapper Syntax (Full Validation) ✅
rust
diag! {
    // Full compile-time validation enabled!
    strict(sequence, primary, component, naming, duplicates),

    // Generate documentation in multiple formats
    <json, html, my_custom_format>,

    E.Auth.Token.MISSING: {
        message: "JWT token not found in Authorization header",
        hints: ["Include 'Authorization: Bearer ' header"],
        role: "public",
    }
}

// Compiler will catch:
// - Typos in Auth, Token, or MISSING
// - Wrong naming conventions
// - Duplicate error codes
// - Type mismatches
✅ Recommendation: Use enum wrapper syntax for production code. The compile-time validation catches errors before they reach your users!

Generated Output & Documentation

The error code automatically formats as [E.AUTH.TOKEN.001] → aB3xY and generates documentation in JSON, HTML, and custom formats:

output
{
  "code": "E.AUTH.TOKEN.001",
  "hash": "aB3xY",
  "message": "JWT token not found in Authorization header",
  "hints": ["Include 'Authorization: Bearer ' header"],
  "role": "public"
}

💡 Why Use Macros?

While you can use waddling-errors without macros (as shown in Quick Start), macros provide additional compile-time safety that catches errors before your code even runs.

Without Macros

rust
// Manual approach - more flexible
const ERR: Code = error(
    Component::Autth,  // Typo compiles
    Primary::Token,
    1
);

// No compile-time checks
const ERR2: Code = error(
    Component::Auth,
    Primary::Token,
    9999  // Out of range
);

Errors discovered at runtime

With Macros (Recommended)

rust
diag! {
    strict(component, primary, sequence),

    E.Autth.Token.MISSING: {
        message: "Token missing",
    }
}

// Compiler error immediately:
// error: no constant `Autth` in scope
// help: did you mean `Auth`?

Errors caught at compile time

💡 Key Benefits:
  • Zero runtime overhead - validation happens at compile time
  • Refactoring confidence - rename a component and all usages are checked
  • Team scalability - new developers can't introduce invalid codes
  • Documentation sync - generated docs are always accurate
đŸŽ¯ The Result:

With macros, your error handling system becomes self-documenting, self-validating, and safer to refactor. The compiler becomes your error-checking assistant.

🔍 Compile-Time Validation Deep Dive

âš ī¸ Prerequisite: Compile-time validation requires the enum wrapper syntax (pub enum Component, pub enum Primary, pub SEQUENCE) as shown in Quick Start Step 2. Simple syntax only supports relaxed validation.

Syntax Comparison

Syntax Type Structure Validation Support Use Case
Simple Syntax component! { Auth { ... } } ❌ Relaxed only
No strict() validation
Prototyping, small projects
Enum Wrapper
Recommended
mod components {
  component! {
    pub enum Component { ... }
  }
}
✅ Full strict() support
All 7 validation modes
Production code, team projects

The diag! macro supports 7 granular validation modes to catch errors at compile time:

1. sequence

Validates sequence names exist as const u16 in crate::sequences::
strict(sequence)

2. primary

Validates primary names exist as const &str in crate::primaries::
strict(primary)

3. component

Validates component names exist in crate::components::
strict(component)

4. naming

Enforces naming conventions: UPPER_SNAKE_CASE for sequences, PascalCase for components/primaries
strict(naming)

5. duplicates

Detects duplicate error codes within the same diag! block
strict(duplicates)

6. sequence_values

Type-checks that sequence constants are u16 values
strict(sequence_values)

7. string_values

Type-checks that primary constants are &str values
strict(string_values)

📝 Example: Full Validation

rust
diag! {
    // Enable all validations
    strict(sequence, primary, component, naming, duplicates),

    E.Auth.Token.MISSING: {
        message: "Authentication token not found",
        hints: ["Include Authorization header"],
    },
    W.Parser.Syntax.INVALID: {
        message: "Invalid syntax detected",
    }
}

✨ The compiler will verify: All components exist, all primaries exist, all sequences exist, naming follows conventions, and no duplicate codes within the block.

🌐 Browser-Server Catalog Pattern

Compact error transmission with client-side i18n expansion - transmit 85% less data while supporting multiple languages.

💡 Tip: Click "Play Animation" above to see the full demo of how compact errors flow from server to browser and expand in multiple languages.

đŸ”Ŧ Advanced Features

FOR PRODUCTION SYSTEMS

For complex projects and team environments, waddling-errors offers additional capabilities:

đŸˇī¸ Component Markers

Associate functions, structs, and modules with error components using in_component! macro for better organization and tracing.

Learn more →

đŸ‘Ĩ Role-Based Documentation

Generate separate documentation for public, developer, and internal audiences with role-based filtering.

See examples →

đŸŽ›ī¸ Conditional Error Gating

Enable or disable error codes at compile-time (feature flags) or runtime (environment-based) for different builds.

Learn more →
🔜 COMING SOON

đŸŒŗ Hierarchical Components

Nest components for complex systems with hierarchical error codes like Auth.JWT.Token or DB.Connection.Pool.

Planned for future release
💡 Pro Tip: These features are designed for production environments with multiple teams, large codebases, and complex deployment scenarios. Start simple and adopt these as your needs grow.