Proposal: add std::error::BoxError

Actually, my impression is that the discussion got derailed from „Let's add a simple type alias so people don't have to type Result<_, Box<dyn Error + Send + Sync>> and forget the Send + Sync part half the time“ to „Let's design a new type that hides some details about what it really is and captures backtraces“.

I think the first is blocked only on consensus to go ahead and bikeshed the name.

The second is probably blocked on bunch of different things (discussion if it should capture backtraces, under what circumstances) and one of these things is possibly specialization as such type should implement the Error trait, but should not wrap it into another level of dynamiciness in its From implementation (eg. specializing From<Self> to be identity).

As an aside, I have such type alias in several places, like here: https://docs.rs/err-context/0.1.0/err_context/type.AnyError.html. I work around the fact that the AnyError, which is Box doesn't implement Error by having two different extension traits, one for E: Error types, another (looking the same) for the Box<Error> types (https://docs.rs/err-context/0.1.0/err_context/trait.ErrorExt.html, https://docs.rs/err-context/0.1.0/err_context/trait.BoxedErrorExt.html).

3 Likes

@vorner I just added a type along those sorts of lines to the Abscissa framework today (in order to remove failure and switch to pure std::error::Error):

1 Like

Ok I'll write an RFC for this (unless a PR is more appropriate)

Note that there have been some recent discussions about trying to improve error handling in std, and in particular, any proposed solution here should provide forward-compatibility with further extensions such as contexts.

1 Like

Could you signpost me to these conversations, assuming they are public

Various different places. Take a look at the anyhow and thiserror crates, the proposal for a core Error trait shared among several error-handling crates, and several recent discussions on the /r/rust reddit findable with "error" in the subject.

There isn't consensus on everything we'd want to change, but there seems to be a decent sentiment towards getting the common elements provided by most error libraries into std (and getting some of those bits into core).

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.