Oh, I was going to add a snarky comment saying that ? in tests is useless, and one should just unwrap, and now I am confused as to what I should say :-D Delightful, thanks!
Edit: I admit that it’s less convenient than having the standard library do this for everyResult, presumably only in debug mode, but the compiler support to build this has been available since Rust 1.46.
This is a very cool idea! I’ve attempted something similar in the past, which led to me creating a little utility crate that shows propagation points automatically, by just switching out result types: https://github.com/zesterer/errant
It would be nice to have better approaches to this baked into the main language, Rust’s lack of decent backtraces is probably the #1 thing I dislike about error handling in the language today.
I feel like it would be good to combine the two, since testresult still can’t give the line of code in the original function, it only can identify where in the test function it failed.
Seems like something like errant would be nice to have on by default in test builds for Rust.
I think they’re solving the same problem but in a different way: testresult is an 80% solution that basically “fixes” using ?s in tests and that’s it while errant provides a more complete solution at the cost of a couple (transitive) dependencies.
since testresult still can’t give the line of code in the original function, it only can identify where in the test function it failed.
Yeah, but (at least in my case) that’s where the assertion that may fail is - directly in the test function.
Seems like something like errant would be nice to have on by default in test builds for Rust.
It looks like this can be achieved by adding errant as a dev-dependency and then marking use errant::prelude::*; with #[cfg(test)] or do you mean something more built-in?
The anyhow crate has a “backtrace” feature flag, which enables adding backtraces automatically.
It’s certainly not as neat as this though in the output though, as it just splats the entire backtrace, where this gives the meaningful part.
Oh, I was going to add a snarky comment saying that
?in tests is useless, and one should just unwrap, and now I am confused as to what I should say :-D Delightful, thanks!That PR is so wholesome! That’s what FOSS is all about.
Could the compiler implement an API on Result that appends each location being error-returned from?
One can do that today in a library: e.g., my preferred Rust error library, Snafu: https://docs.rs/snafu/0.7.4/snafu/struct.Location.html.
Edit: I admit that it’s less convenient than having the standard library do this for every
Result, presumably only in debug mode, but the compiler support to build this has been available since Rust 1.46.This is a very cool idea! I’ve attempted something similar in the past, which led to me creating a little utility crate that shows propagation points automatically, by just switching out result types: https://github.com/zesterer/errant
It would be nice to have better approaches to this baked into the main language, Rust’s lack of decent backtraces is probably the #1 thing I dislike about error handling in the language today.
I feel like it would be good to combine the two, since
testresultstill can’t give the line of code in the original function, it only can identify where in the test function it failed.Seems like something like
errantwould be nice to have on by default in test builds for Rust.I think they’re solving the same problem but in a different way:
testresultis an 80% solution that basically “fixes” using?s in tests and that’s it whileerrantprovides a more complete solution at the cost of a couple (transitive) dependencies.Yeah, but (at least in my case) that’s where the assertion that may fail is - directly in the test function.
It looks like this can be achieved by adding
errantas a dev-dependency and then markinguse errant::prelude::*;with#[cfg(test)]or do you mean something more built-in?The anyhow crate has a “backtrace” feature flag, which enables adding backtraces automatically. It’s certainly not as neat as this though in the output though, as it just splats the entire backtrace, where this gives the meaningful part.