​
Purpose

Shared error hierarchy, serialization, context wrappers, error codes, and IO mapping. This page follows the real source shape for Trace Errors and explains the workflow a developer is likely to use first.

​
Developer workflow

Start from the smallest constructor or builder, perform one meaningful operation, inspect the returned state, then add the relevant policy, storage, or network integration. The examples below should be expanded whenever the crate API changes.

​
Primary types to know

  • SerializedError — libs/trace-errors/src/lib.rs
  • CryptoError — libs/trace-errors/src/lib.rs
  • ErrorCode — libs/trace-errors/src/lib.rs
  • OwnershipError — libs/trace-errors/src/lib.rs
  • ProtocolError — libs/trace-errors/src/lib.rs
  • ReplicationError — libs/trace-errors/src/lib.rs
  • StorageError — libs/trace-errors/src/lib.rs
  • TraceError — libs/trace-errors/src/lib.rs
  • ValidationError — libs/trace-errors/src/lib.rs
  • ErrorContext — libs/trace-errors/src/lib.rs
  • ToIoErrorKind — libs/trace-errors/src/lib.rs

​
Example shape

use trace_errors::*;

// Minimal example skeleton. Replace placeholders with the concrete constructor
// listed on the API Surface page for this library.
async fn example() -> Result<(), Box<dyn std::error::Error>> {
    // 1. Build config or open storage.
    // 2. Execute one operation from this page.
    // 3. Assert the observable result before wiring peers or persistence.
    Ok(())
}

​
Release-quality documentation checklist

  • Every public type on the API Surface page has at least one sentence of behavior documentation.
  • Every fallible operation lists errors and recovery guidance.
  • Every networked example names the peer/session/topic lifecycle.
  • Every storage example names durability, repair, and deletion semantics.