Should snafu errors have the ability to display the report by default?

[Frederik-Baetens]

Eyre allows users to configure the default display implementations for errors generated by Eyre, so that just doing println!("{e}"); will show the full error chain. Snafu has a similar Report type that works in a very similar way, but with the critical difference that it seems that one needs to explicitly convert snafu errors to the Report type in order for the error chain to get reported properly.

This is not a big deal in classic CLI use cases where it's often sufficient to just put #[snafu::report] on the main function. However, in server applications, which may have many asynchronous background loops, errors often just get printed immediately where they're observed, without there being a centralized place to report (and convert) these errors.

This leads to it being very easy to accidentally just use println!("{e}"); instead of println!("{}", Report::from_error(e));, causing the full error chain to not be displayed in our logs. Having similar functionality to eyre, where we could configure the default display impl for these errors would be useful in that we could enable the full error chain to always be reported, removing the need to always pay attention to whether errors are being correctly logged.

Is a change like this something that would fit in the Snafu crate? If so, I'd be happy to try to contribute this functionality.

[Frederik-Baetens]

I suppose that #[snafu(display("error happened: {source}"))] achieves this somewhat, but that still won't walk the full error chain like Report does to my understanding.

[Enet4]

The matter of providing a display implementation which prints the source is frequently brought up. I hope the comments in #390 explain the key concerns eloquently.

SNAFU provides control over a SNAFU error type's fmt::Display message while also following the behavior recommended by the error handling working group for its implementation, so when the source is exposed, it must not display it. For the default Display implementation without extra formatter options, this behavior would be non-negotiable.

If anything, there may be something SNAFU can do to more intuitively accommodate the scenario that Eyre users are already familiar with, though as far as I can tell we haven't reached any consensus on this. There is a report implementation, and it is understood that people want to use it for reporting, but they might forget to use it, since unlike eyre's Report, the means to report an error is separate from the error itself.

[shepmaster]

There's also some discussion in #520.

the means to report an error is separate from the error itself

This follows with what I expect will be stabilized someday via std::error::Report.

---

use println!("{e}"); instead of println!("{}", Report::from_error(e));,

How literal is this example? If 100%, I'd go for "make a helper function print_error(e)" as a good application-specific solution.

displayed in our logs.

Everyone's logs are different, but most that I've dealt with would prefer something without embedded newlines, so it seems like you wouldn't want to use the multiline Report output as it is today

explicitly convert snafu errors to the Report type

Note that Report works with any type that implements Error and should not be restricted to SNAFU-generated errors. (Ideally, there's zero way of telling that a given error was constructed by SNAFU or not).

---

so when the source is exposed, it must not display it.

This makes me wonder what if we go the opposite direction? What if we had an option that forced Error::source to always return None but in exchange it appended the sources in the display? Handwaving, something like...

#[derive(Debug, Snafu)]
#[snafu(terminal)] // <-- new
#[snafu(display("Oh dear"))]
struct MyError {
    source: AnotherError,
}

// ...
let e: MyError = todo!();
assert!(e.source().is_none());
assert_eq!(e.to_string(), "Oh dear: The `Display` impl for `AnotherError` here");

[Frederik-Baetens]

How literal is this example? If 100%, I'd go for "make a helper function print_error(e)" as a good application-specific solution.

Almost 100% literal, with the difference that we're using the error!/warn!/info! macros from the tracing crate https://docs.rs/tracing/latest/tracing/macro.error.html

I suppose that a custom report_error function or macro would probably solve my concerns here. It's easier to audit whether we're properly using that everywhere instead of println/other macros.

Considering all the context here, I think implementing a custom function macro is a good solution. I think I just need to accept that there should be a difference between how errors are reported & their default display impl, due to how error reporting in Rust is generally designed.

This makes me wonder what if we go the opposite direction? What if we had an option that forced Error::source to always return None but in exchange it appended the sources in the display? Handwaving, something like...

I quite like this suggestion though, and it would likely solve my problem here. (Although over time people would probably complain about not being able to customize this display impl, which might render this less useful again)

[shepmaster]

about not being able to customize this display impl

I had half a thought on that when writing it up, but figured I'd leave it be until it was needed...

#[snafu(terminal)]
// expands to
#[snafu(terminal(snafu::Report::whatever))]

In general, terminal could take a path to a function that will be handed (the error? the first source error?) and returns something that impl Display, which is then dumped after the : .

[shepmaster]

I think implementing a custom function macro is a good solution

You can also flip the script and add a project-specific extension trait, so that you could do e.log().

You could potentially even write the extension trait for Result and bury the pattern matching inside the helper. This depends a lot on what you are doing in the case of an error, of course. That might lead you back to a macro-by-example where you do something like cool_thing!(some_result) and it logs the error and continues or returns or whatever, assuming there's a common pattern.

Another thing in that realm is something akin to map_err, where you take a Result<T, E> and return back a Result<T, ()> after logging it.