undefined | Better HN

0 pointsdwattttt18h ago0 comments

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.

0 comments

the__alchemist17h ago

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)

dwatttttOP16h ago

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.

iknowstuff15h ago

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

awesome_dude13h ago

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

dwatttttOP11h ago

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.

awesome_dude11h ago

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

what11h ago

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.

awesome_dude11h ago

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.

j / k navigate · click thread line to collapse

0 comments

the__alchemist17h ago

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

dwatttttOP16h ago

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.

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

iknowstuff15h ago

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

awesome_dude13h ago

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.

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

dwatttttOP11h ago

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".

awesome_dude11h ago

what11h ago

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.

awesome_dude11h ago

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

j / k navigate · click thread line to collapse