He's not making that up; in practice, you're going to run into and need to make mental space for the idiosyncrasies of multiple error frameworks.

I guess you might have to if you need to use a library someone's written that doesn't implement the standard.

Writing primarily applications, I couldn't tell you what error handling frameworks my dependencies are using: I literally don't know, and haven't needed to know in order to display, fail, or succeed.

EDIT to add: I use anyhow for this, so I should also add "add context to an error when I fall" to the list of things I do.

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

Not sure what you mean by that. If you're consuming the API of a crate that has functions that return errors, you're not really dealing with a "framework", you're just dealing with whatever the `E` is in the `Result<T, E>`. If that `E` doesn't implement std::error::Error, I'd consider that a deficiency (even a bug) for that crate. (Yes, I know some crates want to support use in `no_std` environments; that's what features are for.)

If I care about the specific variants of error that a function can return, so I can do different things depending on what kind of error occurred, I'll read the docs and match. That's not really a "framework" thing; that's just a basic thing that anyone has to do in any language in order to consume an API. If I need to propagate the error, I'll do so (either directly, or by wrapping it in a variant of my own error type). I don't see how any of this is "framework"-y.

A crate's decision to use thiserror (or not) does not matter to me. If a crate exposes `anyhow::Error`, that's a lazy choice and bad API design, but still "works" and I generally don't need to care about it.

Or is there something else you meant when you said "error frameworks"?

Just wanted to add that `Error` has been in core since `1.81` [1], meaning that even `no_std` environments can/should represent errors the same way.

[1] https://doc.rust-lang.org/core/error/trait.Error.html

I’m sorry but this is simply incorrect and I think stems from insufficient understanding of best practices and/or how the Error trait composes, as the other replies alluded to. There’s a lot of reading material on the subject but unfortunately I can’t recommend anything off the top of my head

You get how that last sentence is extremely funny given the first sentence, right?

No. Why, did you feel attacked

How it reads to me: "This is easy. No problem! There's reams of pages written about it, because it's easy, which is always why whole treatises get written about stuff. I can't think of the best to recommend right now, not because the topic is nuanced and there's no best one and you probably have to read many different things to determine whether to e.g. reinvent pointers as integer indexes into arrays, but don't take from any of this the idea that any part of this is complicated. Noooo!"

I mean, you said it way more concisely than I did. Good on you!

I was not asserting it was easy nor trying to attack you. Merely recommending you find reading material because your understanding is lacking. You’ll probably find it scratching an itch when you realize how nicely it all composes together.

Though I have little hope for that after your little drive-by at memory safety further showcasing you’re way out of your depth

I feel pretty comfortable with my level of conversance with these issues, but if you think "you're way out of your depth" is persuading readers of this thread, have at it; you have my permission to establish to those readers that that's the level you're arguing at.