đ Overview
waddling-errors provides structured
diagnostic codes with a consistent
4-part format:
Error Code Format
Convention:
[EC] â H where EC is the error code and
H is the hash
Examples:
[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:
đ Public Documentation
End-user facing errors with helpful hints and solutions. Perfect for API consumers and external developers.
Role: Publicđ¨âđģ Developer Documentation
Internal developer documentation with implementation details and debugging information for contributors.
Role: Developerđ Internal Documentation
Full team visibility with complete error catalog, internal debugging notes, and system architecture details.
Role: Internalđ Quick Start
Get started with waddling-errors using macros for compile-time safety:
Step 1: Add Dependencies
[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):
Option A: Simple Syntax (Relaxed Validation)
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
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;
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)
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) â
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
Generated Output & Documentation
The error code automatically formats as
[E.AUTH.TOKEN.001] â aB3xY and generates
documentation in JSON, HTML, and custom formats:
{
"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
// 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)
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
- 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
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
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
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 SYSTEMSFor 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.
đĨ 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 âđŗ Hierarchical Components
Nest components for complex systems with hierarchical error codes like Auth.JWT.Token or DB.Connection.Pool.