error-stack: Anyhow like simple error propagation

[fominv]

Hi All,

I have been trying out error_stack and I quite like the idea of error layers throughout a rust program. However, sometimes I wish for nicer ergonomics where at the moment I do not want to define a custom type for an error:

use error_stack::{report, Result, ResultExt};
use thiserror::Error;

#[derive(Error, Debug)]
enum ErrorA {
    #[error("error A")]
    A,
    #[error("anyhow")]
    Anyhow,
}

#[derive(Error, Debug)]
enum ErrorB {
    #[error("error B")]
    B,
    #[error("anyhow")]
    Anyhow,
}

fn main() -> Result<(), ErrorB> {
    bar()
}

fn foo() -> Result<(), ErrorA> {
    Err(report!(ErrorA::Anyhow))
    // Err(anyhow!()) // This might be nice
}

fn bar() -> Result<(), ErrorB> {
    foo().change_context(ErrorB::Anyhow)?;
    // foo().anyhow()?; // This might be nice
    Ok(())
}

Let's say that foo does some stuff and returns an error which at the moment, I do not really care about. In that case, I would like to call something like anyhow!().attach_printable("meh") and return.

At the call site, I would like to be able to wrap any error type from a lower level error with anyhow() again (potentially add context or not) in case I do not really care about the error.

The enum variant could also be derived with its own derive macro.

I think this improves the ergonomics of error_stack in cases where one still prototypes an application and does not know the exact error layers at the moment. If at some point one wants more fine grained control, then adding another enum variant and calling .change_context(ErrorB::AnotherVariant) would be simple.

This solves my underlying problem of using other libraries / operations. When they return a result I am sometimes hard pressed of finding names and / or categorizing the error in this layer. I think in that case having a generic Anyhow error with nice ergonomics would make more sense than coming with a probably bad name on the spot.

[indietyp]

Hi @fominv! Thank you for the question.

I sympathize with your want to sometimes not create a new error or a new error layer, but allowing for something as you described would go against the spirit of error-stack. The goal of error-stack is to allow an explicit way to define different layers that propagate up the chain, optionally adding related errors. Allowing a macro like anyhow would circumvent this, as it would promote what we consider an anti-pattern, moving from something explicit to something implicit.

Sure, at the moment, this might seem like a good idea, as one might think: "This is temporary, I will add more details later," but from my experience, this won't happen most of the time, and a once temporary stopgap becomes a permanent fixture, which then leads to confusion in published libraries or displayed errors.

You can use something like an Anyhow variant for your errors. That's fine! I don't see a future where something like this is natively supported in the library.

If you find yourself struggling to find a name for your variant, you might want to consider instead moving to a struct like:

#[derive(Error, Debug)]
struct ErrorB;

This would circumvent the naming issue; if you still want names for your other variants, you can add an intermediary context for those that is a proper enum!

As a side note, you can move between anyhow and error-stack using the provided anyhow integration and with Report::into_error.

[fominv]

Thank you for the quick reply! Will try with the ideas you proposed.