Migrate from failure to thiserror and anyhow#436
Migrate from failure to thiserror and anyhow#436sunfishcode merged 4 commits intobytecodealliance:masterfrom
Conversation
|
Overall this sounds good. My one concern is |
|
I've made this a pull request showing what the progress looks like. This shouldn't be merged until a cranelift release containing the corresponding migration takes place, at which point I can change the git rev references in the This PR carefully does not attempt to semantically change or refactor the approach to error-handling in any portion of the code, to ensure that the change remains straightforward to review. Modules using specific differentiated error types move from The second and third commits make some minor further improvements based on this, which I noticed while working on this change. The second avoids duplicating error messages in wasmtime that already exist in cranelift. The third takes advantage of anyhow's Note that in cranelift-debug, I've avoided migrating away from failure, because it depends heavily on the faerie crate which still uses and exposes |
The failure crate invents its own traits that don't use std::error::Error (because failure predates certain features added to Error); this prevents using ? on an error from failure in a function using Error. The thiserror and anyhow crates integrate with the standard Error trait instead. This change does not attempt to semantically change or refactor the approach to error-handling in any portion of the code, to ensure that the change remains straightforward to review. Modules using specific differentiated error types move from failure_derive and derive(Fail) to thiserror and derive(Error). Modules boxing all errors opaquely move from failure::Error to anyhow. Modules using String as an error type continue to do so. Code using unwrap or expect continues to do so. Drop Display implementations when thiserror can easily derive an identical instance. Drop manual traversal of iter_causes; anyhow's Debug instance prints the chain of causes by default. Use anyhow's type alias anyhow::Result<T> in place of std::result::Result<T, anyhow::Error> whenever possible.
handle_module in wasm2obj manually maps cranelift_codegen::isa::LookupError values to strings, but LookupError values already have strings that say almost exactly the same thing. Rely on the strings from cranelift.
The main() wrapper around rmain() completely matches the behavior of question-mark-in-main (print error to stderr and return 1), so switch to question-mark-in-main.
6625b69 to
33879fb
Compare
|
Updated for the cranelift 0.47 release. |
Both crates switched from failure to anyhow; updating lets us avoid a translation from failure to anyhow within wasmtime-interface-types.
fda862b to
834c370
Compare
This commit takes a similar migration path as proposed in bytecodealliance/wasmtime#436 and shares much of the same motivation. The intention here was originally spawned from using `anyhow` everywhere inside of `wasmtime`!
This commit takes a similar migration path as proposed in bytecodealliance/wasmtime#436 and shares much of the same motivation. The intention here was originally spawned from using `anyhow` everywhere inside of `wasmtime`!
This commit takes a similar migration path as proposed in bytecodealliance/wasmtime#436 and shares much of the same motivation. The intention here was originally spawned from using `anyhow` everywhere inside of `wasmtime`!
The `failure` crate is getting old, and has largely been superseded in the ecosystem by the `anyhow` crate, which better uses the standard library (and which only became possible with Rust v1.34). We should demonstrate more modern techniques to students. See: - bytecodealliance/wasmtime#436 - https://blog.yoshuawuyts.com/error-handling-survey/ - https://internals.rust-lang.org/t/failure-crate-maintenance/12087
* Grep: replace failure crate with anyhow The `failure` crate is getting old, and has largely been superseded in the ecosystem by the `anyhow` crate, which better uses the standard library (and which only became possible with Rust v1.34). We should demonstrate more modern techniques to students. See: - bytecodealliance/wasmtime#436 - https://blog.yoshuawuyts.com/error-handling-survey/ - https://internals.rust-lang.org/t/failure-crate-maintenance/12087 * rustfmt tests file
The
failurecrate invents its own traits that don't usestd::error::Error(becausefailurepredates certain features added toError). (For instance, if you have a function returning justResult<SomeType, Box<dyn Error>>, you can't use?on afailure::error::Errorin such a function.) Thethiserrorandanyhowcrates use the new support instd::error::Error, so they interoperate with other usage of the standard Error trait.Would there be interest in migrating from
failuretoanyhow(and fromfailure_derivetothiserror), if someone provided a pull request doing so?