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.
Vec<Error> is a natural solution here, but
Vec<Error> is not an error by itself)
Error trait isn't naturally implementable for errors that internally contain anything else than a straight chain of causations.
Errortrait 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
where you could access an
Iterator<Item = &dyn Error> or a
&[dyn Error] to get access a tree like structure of causation
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
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
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
Result are the right way to handle multiple-issue scenarios, vs just passing some sort of
FnMut to handle whatever comes up.
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
Is this completely disjoint from error-chain? Or could it be an extension of the existing API?
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
hence the notion of unified API
Last updated: Jan 29 2022 at 09:28 UTC