why havn't implemented Error trait for std::option::NoneError ?

[ZhangHanDong]

Forgot it? Still for other reasons.

[kennytm]

See also: https://internals.rust-lang.org/t/should-noneerror-implement-the-error-trait/6312

[ZhangHanDong]

@kennytm thanks

[dlight]

It seems to me that if NoneError should exist at all, then it should implement Error, otherwise Box<Error> doesn't work.

[aminroosta]

Facing the same issue in 2019 :/

[jacob-greenfield]

@kennytm After looking through the discussion on #42526, I’m getting the impression that it is indeed an oversight that there is no way to convert NoneError to Box<Error> so that you can use optional? on a function that returns Result<T, Box<Error>>.

[skade]

This becomes a prevalent problem in the trainings I give, when people learn about: Box<dyn std::error::Error>, because they also try to coerce optionals.

[bbqsrc]

Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since std::error::Error is quite useful now.

[Mark-Simulacrum]

I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of #42327, I get the impression that the general feeling is that the Try trait design is not ready and Option being convertible to Result via ? is not something we are sure we want.

In particular, these comments are relevant:

• Tracking issue for ops::Try (try_trait feature) #42327 (comment)
• Tracking issue for ops::Try (try_trait feature) #42327 (comment)

[jacob-greenfield]

I actually changed my mind on this one. Now that I think about it, it only really makes sense to use ? on an Option if the enclosing function returns an Option. Otherwise if you want to return a Result you can use .ok_or("message") to indicate what went wrong. The error message could be much better though.

[scottmcm]

I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about NoneError, but with the other possible design you would have explicitly gotten something about Result: !Try<Option>.

[bbqsrc]

I'll note that I think the existence of a NoneError is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure std::error::Error is implemented at least, haha.