Comments (4)
Ah that's somewhat different, that looks like a missing From
impl not a missing Error
impl. I released 1.0.16 with the extra impl to make your second code sample work.
from anyhow.
That impl would be incoherent with the existing pair of impls impl From<T> for T
(libcore) and impl<E> From<E> for anyhow::Error where E: std::error::Error + Send + Sync + 'static
(?
support).
error[E0119]: conflicting implementations of trait `std::convert::From<anyhow::Error>` for type `anyhow::Error`:
--> src/error.rs:313:1
|
313 | / impl<E> From<E> for Error
314 | | where
315 | | E: std::error::Error + Send + Sync + 'static,
316 | | {
... |
320 | | }
321 | | }
| |_^
|
= note: conflicting implementation in crate `core`:
- impl<T> std::convert::From<T> for T;
Can you give a minimal example of code that would want this impl to exist?
from anyhow.
There's a (short) story behind that. A new rustacean colleague had written something like this, with a function panicking with expect
, calling it in main
along with other functions returning standard errors:
use anyhow::Context;
fn with_expect() {
let foo = std::env::var("FOO")
.expect("Env var FOO must be set to provide the foo");
let data = std::fs::read(foo) // Result<_, io::Error>
.expect("Failed to read data");
println!("{:?}", data);
}
fn do_something() -> std::io::Result<()> {
Ok(())
}
fn main() -> Result<(), Box<dyn std::error::Error>> {
with_expect();
do_something()?;
Ok(())
}
I explained that anyhow::Context
would allow to provide the context he added with expect
without panicking. So he ended up with this, which doesn't compile because anyhow::Error
cannot be converted to a stdlib error.
fn with_anyhow() -> anyhow::Result<()> {
let foo = std::env::var("FOO")
.context("Env var FOO must be set to provide the foo")?;
let data = std::fs::read(foo)
.context("Failed to read data")?;
println!("{:?}", data);
Ok(())
}
fn main() -> Result<(), Box<dyn std::error::Error>> {
with_anyhow()?;
do_something()?;
Ok(())
}
The solution of course is to change the return type of main
to Result<(), anyhow::Result>
(or even anyhow::Result<()>
but being a new rustacean he couldn't find why anyhow
which is supposed to help in error handling was causing these compilation errors and was confused to no end.
There was an implicit assumption that an anyhow::Error
was also a std::error::Error
or at least implemented Into<std::error::Error>
so that '?' would work with a Box<dyn std::error::Error>
return type.
Error handling is still a hard thing for people new to Rust because of lack of standardization around std::error::Error
caused by the fact that Result
doesn't mandate its error part to implement it. I guess it's to support no_std
but newcomers easily assume that Result
and std::error::Error
go hand in hand and can be confused to no end by that.
from anyhow.
Awesome! Indeed this was actually more about having aFrom
than a missing impl
. Thanks a lot!
from anyhow.
Related Issues (20)
- Nightly feature wrongly enabled on stable toolchain HOT 3
- Should `anyhow::Error::chain` return `dyn Error + Send + Sync` HOT 2
- Customize backtrace logic?
- `anyhow!(e)` doesn't preserve `source` for `&Error` HOT 1
- A way to disable anyhow stacktraces (without disabling stacktraces from other crates) HOT 2
- Default Ok-type to `()` in `anyhow::Result` typedef HOT 2
- Updating from version 1.0.76 breaks backtraces HOT 2
- Make backtrace support optional HOT 10
- Possible performance regression on Windows HOT 5
- as_ref() type must be known at this point
- Depending on `CARGO_ENCODED_RUSTFLAGS` may produce stale builds HOT 1
- rust-analyzer nightly throws needless_return warning on bail! HOT 2
- Implement Context for Error
- Question regarding stacktrace
- anyhow::Error to Box<dyn Error> isn't compatible with other libraries HOT 2
- Are you open to de-duplicating the build.rs build probe code? HOT 7
- `anyhow::ensure!` doesn't work with custom error type HOT 1
- Short backtrace HOT 2
- Feature suggestion: ensure_some!() for unwrapping options HOT 3
- Cannot compile when using `ensure!` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from anyhow.