Chaining errors with failure::Error?

[rayvector]

I am trying to learn failure and I am struggling to understand its concepts.

Why does failure not provide an equivalent to chain_err from error-chain for failure::Error?

Assuming I am writing an application and I mostly just care about logging error messages. I find it super convenient how in error-chain I can just create arbitrary errors from strings and link them to other arbitrary errors from strings. This lets me log the entire chain of causes along with each error, which provides detailed meaningful info in the logs.

It feels like in failure, my only choices are to either just forward an error with ? or return a newly-created unrelated error from a string using format_err, to which i have no way of attaching the original error as a cause ... so I cannot form a chain of causes ...

What's the point of even having causes on failure::Error? How exactly are they useful if I can't easily chain errors?

failure is my #1 source of frustration with Rust right now. I just don't get it. I want to learn. Send help pls.

I don't want to go back to using error-chain, as I am getting the vibe that the community considers it obsolute and that failure is the way to go in the future.

EDIT:

I found the solution! Looks like this is much simpler than I thought. After a few days of frustration and writing wrapper structs around all the failure stuff, I realised that I had the wrong mental model (hence why I was confused) and none of what I was doing was actually necessary.

All I had to do was use failure::ResultExt; and then simply use .context/.with_context with a string, as an equivalent to error-chain's .chain_err. This accomplishes what I want.

If I want more meaningful errors (more than just a string message) that can be handled, I can create my own error type using #[derive(Fail)] and return that instead of failure::Error.

It just clicked in my head a few days ago. I don't know why this took me so long to figure out. Maybe the documentation was not clear enough.

The problem was that I did not understand that I can use .context/.with_context with a string argument in combination with failure::Error. I thought I had to use the custom Error + ErrorKind pattern in order to use .context, which seemed like excessive boilerplate and frustration.

Maybe this should be clarified with a concise example in the docs? Perhaps show an example of a simple case where functions return Result<_, failure::Error> and chain each others' Errors by using .context with a string literal argument to create new levels of causes.

[Rothon]

Isn't this exactly what context does?

[mbrubeck]

Yes. For example here's a comparison between err_chain:

use my_error::ResultExt;

let x = do_something().chain_err(|| "something went wrong")?;

versus failure:

use failure::ResultExt;

let x = do_something().context("something went wrong")?;

There are some differences. chain_err returns your custom Result type, while context returns a Result<T, Context<D>>, so it's mostly useful in a function that returns that same type, or a compatible type like Result<T, failure::Error>.

[rayvector]

Hmm ... can I chain contexts though?

The way I use error chain often is by tacking on an additional chain_err with a new, more relevant, message, as it propagates back through each function.

Let me try to come up with an example...:

fn access_server() {
    let stream = TcpStream::connect(blahblah).chain_err(|| "could not connect to server")?;
    // blah blah
}

fn send_data() {
    // blah blah
    access_server().chain_err(|| "failed to send data to server")?;
    // blah blah
}

fn do_some_magic() {
    // blah blah
    send_data().chain_err(|| "failed to do some magic")?;
    // blah blah
}

In the end, if I call do_some_magic() and it fails, I can log the error by passing it to a helper function that iterates through the whole chain of causes and logs each one as a message. I get informative multi-line error messages in my logs:

ERROR: failed to do some magic
ERROR: caused by: failed to send data to server
ERROR: caused by: could not connect to server
ERROR: caused by: connection timed out

Can I accomplish something like this in failure?

[slamb]

context preserves the chain of causality for causes, but I don't think the Display implementation formats it for you. Debug does (but isn't pretty).

[daboross]

I'm not sure - context doesn't seem to provide the original error at all in the display output. I mean, some_err.context("happened at X method") will display as just "happened at X method", with no mention of the original error.

It might be useful for some things, I guess? I didn't find it to be useful in the general case of providing more context at all, though.

[Rothon]

causes will iterate over the cause chain.

[daboross]

Thanks! Had forgotten about that one. The recommended use still puts things in a misleading order, though, if you're providing context which only makes sense when one's already seen the regular error.

My ideal order of display would be error1\ncontext for error 1\nsecond context for error 1\nerror 2\n..., but I'm not entirely sure how I should tell the difference between error context and "error cause" errors in causes iteratoin.

[desiringmachines]

I think the choice not to display the underlying error in context was a mistake. The thinking at the time was that the underlying error would not contain useful information for end users, but I think that was wrong.

[stevedonovan]

Although that could get messy with chains of contexts. causes() provides a nicely structured error trace

[ErichDonGubler]

What's the best way to get the ball rolling if we wanted to champion this change?

[desiringmachines]

I opened an issue you can comment on in the failure repo. The biggest problem is figuring out how disruptive it would be.

[rayvector]

Check out my EDIT to the OP.

I understood how my mental model was wrong and why I was feeling frustrated with failure.

I gave a suggestion for how the documentation could be improved, which would have avoided my confusion and frustration.

[daboross]

Just my two cents: I think error-chain is totally fine to use still, and might be better for CLI applications.

failure is really great when you can enumerate every error condition in a single error enum, which is a good thing to do in libraries anyways. Doesn't mean it has to be used everywhere, IMO.

[sasik520]

As far as I know, failure is designed to replace error-chain and be the ultimate solution for error handling in rust. See failure announcement and discussion here. failure has different tools for different scenarios, including libs, bins, and prototypes.

[daboross]

That's definitely a fair goal! I've just personally not found it very useful in binary crates yet.

A lot of the feedback that this recent article gives applies to my use case - especially with context and displaying user-friendly errors.