batch_result
Do not fail fast ,collect results and errors then decide,
batch_result is dynamic result batch handling, aggregates results from multiple independent tasks and
classifies the overall outcome heuristically (e.g. Excellent, Partial, Poor).
This crate intentionally does not model workflows:
- it does not enforce execution order
- it does not express dependencies between phases
- it does not require mandatory completion of any phase
batch_result is designed for tasks where tasks are independent, and where
the goal is evaluation and reporting, not control flow or orchestration.
When to Use batch_result
-
Test / validation pipelines
-
Tasks with independent phases
-
Partial success is meaningful
-
Diagnostics matter more than strict pass/fail
-
You want evaluation, not control flow
When Not to Use batch_result
-
Strict workflows or state machines
-
Tasks with required execution order
-
Must-complete or transactional pipelines
-
Security-critical or atomic operations
The Problem
// Traditional approach - fails at first error
let results: = items
.iter
.map
.collect?; // Stops at first error!
The Solution
//add batch_result and toml to your dependencies
//for this example
//BoxedDynError is defined inside batch_result module
//as Box<dyn Error + Send +Sync>
//helpers to simulate the tasks
Another Example with Concrete return types
//add batch_result to your dependencies
//helpers to demonstrate only
Installation
[]
= "0.1.0"
Why not Result<Vec<T>, E>?
| Approach | Behavior |
|---|---|
Result<Vec<T>, E> |
Stops at first error |
batch_result |
Collects all outcomes |