Avoid use of anyhow
#161
Labels
Comments
mkulke
added a commit
to mkulke/regorus
that referenced
this issue
Apr 24, 2024
fixes microsoft#161 This change replaces stringly-typed anyhow errors with thiserror-constructed explicit error enums. The following strategy has been used in the conversion: - Every module maintains its own error enum - Exception is builtins/*.rs in which all errors are consolidated in one enum to avoid duplication - Source errors are being wrapped and propagated in the error string - Crate-specific businesslogic errors have been convernted into their own enum - A simple `bail!` macro has been added to reduce changes - Extension fn's require a `Box<dyn std::error::Error>` error type. it would be nice if the Extension fn's could have a result with trait bound `std::error::Error` but that requires some unergonomic type gymnastics on the trait + impls - A local type alias for `Result` has been added to modules to reduce changes in the Signatures where reasonable. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
mkulke
added a commit
to mkulke/regorus
that referenced
this issue
Apr 24, 2024
fixes microsoft#161 This change replaces stringly-typed anyhow errors with thiserror-constructed explicit error enums. The following strategy has been used in the conversion: - Every module maintains its own error enum - Exception is builtins/*.rs in which all errors are consolidated in one enum to avoid duplication - Source errors are being wrapped and propagated in the error string - Crate-specific businesslogic errors have been convernted into their own enum - A simple `bail!` macro has been added to reduce changes - Extension fn's require a `Box<dyn std::error::Error>` error type. it would be nice if the Extension fn's could have a result with trait bound `std::error::Error` but that requires some unergonomic type gymnastics on the trait + impls - A local type alias for `Result` has been added to modules to reduce changes in the Signatures where reasonable. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
mkulke
added a commit
to mkulke/regorus
that referenced
this issue
Apr 24, 2024
fixes microsoft#161 This change replaces stringly-typed anyhow errors with thiserror-constructed explicit error enums. The following strategy has been used in the conversion: - Every module maintains its own error enum - Exception is builtins/*.rs in which all errors are consolidated in one enum to avoid duplication - Source errors are being wrapped and propagated in the error string - Crate-specific businesslogic errors have been convernted into their own enum - A simple `bail!` macro has been added to reduce changes - Extension fn's require a `Box<dyn std::error::Error>` error type. it would be nice if the Extension fn's could have a result with trait bound `std::error::Error` but that requires some unergonomic type gymnastics on the trait + impls - A local type alias for `Result` has been added to modules to reduce changes in the Signatures where reasonable. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
mkulke
added a commit
to mkulke/regorus
that referenced
this issue
Apr 24, 2024
fixes microsoft#161 This change replaces stringly-typed anyhow errors with thiserror-constructed explicit error enums. The following strategy has been used in the conversion: - Every module maintains its own error enum - Exception is builtins/*.rs in which all errors are consolidated in one enum to avoid duplication - Source errors are being wrapped and propagated in the error string - Crate-specific businesslogic errors have been convernted into their own enum - A simple `bail!` macro has been added to reduce changes - Extension fn's require a `Box<dyn std::error::Error>` error type. it would be nice if the Extension fn's could have a result with trait bound `std::error::Error` but that requires some unergonomic type gymnastics on the trait + impls - A local type alias for `Result` has been added to modules to reduce changes in the signatures where reasonable. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
mkulke
added a commit
to mkulke/regorus
that referenced
this issue
Apr 24, 2024
fixes microsoft#161 This change replaces stringly-typed anyhow errors with thiserror-constructed explicit error enums. The following strategy has been used in the conversion: - Every module maintains its own error enum - Exception is builtins/*.rs in which all errors are consolidated in one enum to avoid duplication - Source errors are being wrapped and propagated in the error string - Crate-specific businesslogic errors have been convernted into their own enum - A simple `bail!` macro has been added to reduce changes - Extension fn's require a `Box<dyn std::error::Error>` error type. it would be nice if the Extension fn's could have a result with trait bound `std::error::Error` but that requires some unergonomic type gymnastics on the trait + impls - A local type alias for `Result` has been added to modules to reduce changes in the signatures where reasonable. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
anakrish
added
enhancement
|
with the recent addition of no-std targets, we probably cannot use thiserror in the near term. The generic error trait is in There are similar libs with no-std support, but maybe the macro niceties are not required and we can do a bit boilerplate ourselves. looking into that. |
|
Interesting that |
|
this makes sense, because afaiu thiserror is just an elaborate machinery of helper-macros that will desuger into implementations of the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Avoid use of
anyhowin Regorus.Turns out
ThisErroris notno_stdcompatible.Original description:
According to comparison,
"Use Anyhow if you don't care what error type your functions return, you just want it to be easy. This is common in application code. Use thiserror if you are a library that wants to design your own dedicated error type(s) so that on failures the caller gets exactly the information that you choose".
The errors in Regorus need to be changed to ThisError.
The text was updated successfully, but these errors were encountered: