What's the standard? I'm not being snarky; I'm going down the thought process of how this would work in practice.

I am on team Io Error [on std rust]", somewhat arbitrarily. If I call a lib that is on Team Anyhow, or Team Custom Error Enum, I will have to do some (Straightfoward, but a little clumsy) conversions if I want ? to work. This is complicated by being able to impl From<ErrorType1> for ErrorType2 only in one direction if you don't control the other crate. (due to the orphan rule)

By standard I meant an error type that implements std::error::Error.

EDIT: Which I assume all my dependencies have done, given that anyhow is able to consume all of them.

I specifically called out writing applications as my use case: my only objection to tptacek's note is the somewhat universal "in practice". The burden for designing errors for a library that others will use is higher, but that's far from the default/universal experience.

Many more people are going to consume libraries & not produce any of their own, and I think my experience is representative there.

There is no team io::Error. There is only one standard: https://doc.rust-lang.org/core/error/trait.Error.html

Not rust specific, and most certainly not a criticism of you - but I hate when people call a lib that errors, then just bubble that error up.

I mean the error is supposed to be tailored to the audience - I guess what you are saying is that you handle the error by saying "I called foo with X, Y, Z, and got this error back" in the logs - which your caller then also does - producing a log message of

ERROR: I called Foo with X Y and Z and got error: Die MF die

followed by

ERROR: I called Bar with X Y Z and a and got error: ERROR: I called Foo with X Y and Z and got error: Die MF die mf (still fool)

And so on and so forth.

If the counter is - don't log, that's fine, but you have to know where in the call graph that error state was reported to the logs

You’re supposed to bubble errors up to the level that can appropriately deal with them? You don’t need to log them each step of the way.

Yeah - but that's the same as my final point - you have to know who is supposed to manage the error/log - all the way up (and down) the call graph

edit: I've just finished debugging a multi system chain - FE -> SNS -> SQS -> Lambda -> DynamoDB -> Lambda -> Webhook -> My poor code

My code has multiple layers - and I was trying to find where in the very long chain of calls the data was being mangled

It turned out that there was an unlogged error, which was mismanaged by a caller - there's no shade here - the caller was handling the error how it was designed to, but by not logging that there was an error - it took a minute to understand.

I have tried to figure out some kind of unification between "collecting error state in a function", "logging error state", and "return error state to a parent".

I haven't found any satisfying solution to it all; collecting information for logging vs information that a caller would want... I've been meaning to investigate tracing_error to see if it brings it all together.

Regardless of language - if you find a good, clear answer - blog the hang out of it - I for one have been searching for the right way to manage this, and it's not (yet) clearer - other than what I've said so far

tracing_error is a nice option if you already have the tracing context.

snafu makes it easy to attach structured context to an error