upvote

points

by dwattttt20 hours ago |
comments
upvoteby the__alchemist19 hours ago|
next
[-]
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)

reply
upvoteby dwattttt19 hours ago|
parent|
next
[-]
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.

reply
upvoteby iknowstuff17 hours ago|
parent|
prev|
[-]
There is no team io::Error. There is only one standard: https://doc.rust-lang.org/core/error/trait.Error.html
reply
upvoteby awesome_dude15 hours ago|
prev|
[-]
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

reply
upvoteby dwattttt13 hours ago|
parent|
next
[-]
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.

reply
upvoteby awesome_dude13 hours ago|
parent|
[-]
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
reply
upvoteby 14 hours ago|
parent|
prev|
next
[-]
deleted
reply
upvoteby what13 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby awesome_dude13 hours ago|
parent|
[-]
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.

reply