From 5b3c11f04a8b20531f2da5efdeb6c299eaf3d6eb Mon Sep 17 00:00:00 2001 From: mcmah309 Date: Wed, 11 Sep 2024 21:06:02 +0000 Subject: [PATCH] doc: Update --- README.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index c394fe0..eb1c028 100644 --- a/README.md +++ b/README.md @@ -552,7 +552,7 @@ result.swallow_with_debug(|err| format!("Debug info: {:?}", err)); common to Rust developers. Like `thiserror`, `error_set` allows you define errors, their display messages, and conversions between errors. However `error_set` -is approximately 50% more concise more maintainable: +is approximately 50% more concise and maintainable:
@@ -601,8 +601,7 @@ error_set! {
-With `error_set` there is no need to maintain a web of nested wrapped enums (with `#[from]`). With `error_set` there is no -nesting and all the `From` implementations are automatically generated in one error type is a subset of another. +With `error_set` there is no need to maintain a web of nested wrapped enums (with `#[from]`), since there is no nesting, and all the `From` implementations are automatically generated if one error type is a subset of another. Like `anyhow`, `error_set` attempts to capture the context around errors. To accomplish this, it uses the help of `tracing`/`log` crate. See the feature flags section for more info. However, if your project doesn't require handling specific error types and you just need to propagate errors up the call stack, then `anyhow` is likely a good choice for you. It's straightforward and skips the need to define error types all together.