Stream: project-error-handling

Topic: Multiple errors


view this post on Zulip nagisa (Oct 19 2021 at 21:07):

One of the things that Rust ecosystem I think didn't solve yet is a situation where a single function call wants to return multiple errors at once.

view this post on Zulip nagisa (Oct 19 2021 at 21:07):

(Vec<Error> is a natural solution here, but Vec<Error> is not an error by itself)

view this post on Zulip nagisa (Oct 19 2021 at 21:09):

and the Error trait isn't naturally implementable for errors that internally contain anything else than a straight chain of causations.

view this post on Zulip Jane Lusby [she/her] (Oct 19 2021 at 21:16):

nagisa said:

and the Error trait isn't naturally implementable for errors that internally contain anything else than a straight chain of causations.

generic member access specifically seeks to resolve this

view this post on Zulip Jane Lusby [she/her] (Oct 19 2021 at 21:16):

where you could access an Iterator<Item = &dyn Error> or a &[dyn Error] to get access a tree like structure of causation

view this post on Zulip Jane Lusby [she/her] (Oct 19 2021 at 21:17):

nagisa said:

(Vec<Error> is a natural solution here, but Vec<Error> is not an error by itself)

I expect that at least short term we will still want to rely on users to wrap Vec<Error> in their own types that expose the proper api for adding additional errors and re-exposing them through generic member access

view this post on Zulip Jane Lusby [she/her] (Oct 19 2021 at 21:19):

it will be interesting to see how it develops though, my feeling is that once generic member access lands all the pieces will be there for errors with multiple causes for things like parsers, but the reporting element of it and how to re-expose those multiple sources through the error trait seems like it could run into issues where people can't decide on a consistent interface (aka type parameter via generic member access) to return the sources as

view this post on Zulip scottmcm (Oct 20 2021 at 05:44):

FWIW, AggregateException in C# is a royal pain -- it tends to in practice obscure what actually happened and "normal" ways of using exceptions end up just losing all the extra information.

It's not obvious to me that Error and Result are the right way to handle multiple-issue scenarios, vs just passing some sort of Extend or FnMut to handle whatever comes up.

view this post on Zulip scottmcm (Oct 20 2021 at 05:47):

There was a URLO thread about this a while back -- I think it was https://users.rust-lang.org/t/continue-execution-even-if-the-result-is-err-and-return-an-error-later/17349/8?u=scottmcm

view this post on Zulip Jakub Duchniewicz (Oct 30 2021 at 11:10):

Is this completely disjoint from error-chain? Or could it be an extension of the existing API?

view this post on Zulip Jakub Duchniewicz (Oct 30 2021 at 11:11):

from what Jane said it looks like there is a threat of non-uniform usage of this API if we leave it to the users to use Generic Member Access for this

view this post on Zulip Jakub Duchniewicz (Oct 30 2021 at 11:11):

hence the notion of unified API


Last updated: Jan 29 2022 at 09:28 UTC