Rust: 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 :/

[Coder-256]

@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 https://github.com/rust-lang/rust/issues/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:

• https://github.com/rust-lang/rust/issues/42327#issuecomment-366840247
• https://github.com/rust-lang/rust/issues/42327#issuecomment-376772143

[Coder-256]

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.

[nixpulvis]

If NoneError is to exist, then it should implement Error, otherwise a better name should be chosen for the ? try trait result.

But generally, I think I'd like to be able to use ? in functions returning Result on either Result or Option types (without explicit conversion), while only allowing use on Option types in functions that return Option. Does this make sense?

[ZhangHanDong]

I don't think should implement Try for Option<T>.

None is not an error, it is just a state that may cause errors.

If Option does not implement Error, then try block does not need Ok-wrapping.

If you don't have any ? inside, then with ok-wrapping there is no real information about what the "wrapper type" should be (i.e., should try { 3 } have the type Option or Result, and what should _ be?)
from niko

[ZhangHanDong]

Should NoneError implement the Error trait?

Niko

Just a note

[skade]

I see the issue that Try for Error is already on stable.

[scottmcm]

Note that as of right now, it's absolutely by design that NoneError doesn't implement Error, because it's by design that you can't ? on Option in something returning Result<_, Box<dyn Error>>.

It's also unstable for a reason. We have a meeting planned about redesigning the current Try approach, which will likely remove NoneError from being involved in ?-on-Option.

I strongly discourage anyone from trying to hack around this restriction. Just use .ok_or(GoodReason) if you want to early-return on None in a Result-returning function.