There must be some downside to doing this? That is, why wouldn't the '?' operator already give us this kind of important detail?
Correctly, you will get an error that this is not possible because you would be drenched with water.
In addition, with this crate, you will also get the information that this error was returned in washing_machine.rs:3562. Thanks, I guess?
>That is, why wouldn't the '?' operator already give us this kind of important detail?
It's just not very useful information to have, except for the original developer (when debugging)--and the latter is a minority use case. Rust doesn't make you pay for things you don't use.
But for this feature Rust would need to add an integer (and possible alignment bytes) and a str reference every single time there is a "?" (there are a lot of those) and an error is constructed, also when not debugging.
This crate requires you to add `#[wherr]` in order for it to change what `?` does--and you would only do that when debugging. That's nice.
Very, very few end up in front of an end user. Typically only in a CLI.
However, I imagine real-world use-cases when it's preferable to pay that cost in production, allowing users to forward file and line information to the original developer via a bug report.
Alternatively, indirectly, for instance via some company's customer support, that might ask the customer to include output from their program, which they in turn can let their developers analyse, who in turn can contact the developer of the library used, where the error originates from.
Not having this information in production, means the original developer will need to try to figure out how to reproduce the error locally, which might be necessary anyway of course, but the effort will probably be less, given the file and line information.
That said, I agree with you that the most likely use-case, is to enable this only when debugging, on a per-function basis, when needed.
Yes, that's awesome. I can either dig into the code myself or at least forward it to the project and get a great pinpointed report (at least some of the time). Much better than searching for strings and trying to guess what was parametrized.
This is definitely something that you would want in production/in customer deployments. The only reason not to want this is extremely tight optimization scenarios, where paying the cost of the larger error type is too much (or if you're returning errors on some hot path).
So I'm not questioning the why of adding these, but was wondering why '?' doesn't have a way to do this for us already.
#[derive(Debug)]
enum MyError {
A,
B,
C
}
impl std::fmt::Display for MyError {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
write!(f, "{:?}", self)
}
}
impl std::error::Error for MyError {}
// Equivalent to wherr::Wherr.
#[derive(Debug)]
struct ErrorWrapper {
inner: Box<dyn std::error::Error>
}
impl std::fmt::Display for ErrorWrapper {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
self.inner.fmt(f)
}
}
impl std::error::Error for ErrorWrapper {}
fn my_error() -> Result<(), MyError> {
Err(MyError::A)?
}
// Equivalent to applying #[wherr] to my_error.
fn my_error_wrapped() -> Result<(), ErrorWrapper> {
Err(ErrorWrapper { inner: Box::new(MyError::A) })?
}
fn main() {
// Works.
match my_error().unwrap_err() {
MyError::A => { println!("got MyError::A"); }
_ => { println!("got some other MyError variant"); }
}
// Doesn't work: how do I match out the inner MyError?
match my_error_wrapped().unwrap_err().inner {
MyError::A => { println!("got MyError::A"); }
_ => { println!("got some other MyError variant"); }
}
} // This will work: downcast the inner error and then match on it.
match my_error_wrapped().unwrap_err().inner.downcast_ref::<MyError>() {
Some(MyError::A) => println!("got MyError::A"),
Some(_) => println!("got some other MyError variant"),
None => println!("got an unknown error type"),
}I couldn't figure out how to make it work though, since with these changes, now nested functions using the #[wherr] macro won't work due to "doesn't have a size known at compile-time".
The other idea of just using #[track_caller] also seems promising, and will be considered for a future major version.
But I still think it's interesting if the macro variant can be improved, to avoid having to do dynamic casts, hence this new branch.
If you can see a solution that doesn't require boxing, that could make an interesting blog post, or PR to this crate!