libcore/Result - Add an expect method that prints a message and the Err value
#25359
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
thepowersgang
force-pushed
the
result-expect-2
branch
from
7cf73d3 to
dddb10c
Compare
| /// x.expect("Testing expect"); // panics with `Testing expect: emergency failure` | ||
| /// ``` | ||
| #[inline] | ||
| #[unstable(feature = "core", reason = "newly introduced")] |
There was a problem hiding this comment.
I think we're trying to use more specific features now, so maybe something like result_expect instead of core here?
There was a problem hiding this comment.
Will update to use result_expect
|
👍 this is something I've been thinking about adding for a while. |
| @@ -729,6 +729,26 @@ impl<T, E: fmt::Debug> Result<T, E> { | |||
| panic!("called `Result::unwrap()` on an `Err` value: {:?}", e) | |||
There was a problem hiding this comment.
This could now turn into just self.expect("called Result::unwrap() on an Err value").
There was a problem hiding this comment.
Should I add that to this PR, or leave it as is?
There was a problem hiding this comment.
(it's fine to add this to this PR)
thepowersgang
force-pushed
the
result-expect-2
branch
from
b012a13 to
f6ee937
Compare
|
This addition needs an RFC, see RFC guidelines |
|
I see absolutely no reason why we shouldn't have this method. |
|
@bluss I will prepare an RFC |
|
RFC PR rust-lang/rfcs#1119 |
|
I also constantly 'expect' this method to exist, and reluctantly agree that it's important enough to put through the RFC process. |
|
@brson, I'm sorry to be so dull but you could update the RFC guidelines to say that rust team can use their judgement and merge methods as they wish instead. But that's not what they say today :). I like this particular change but that makes this an easy case -- send it to RFCs. I want to follow the process that's laid out or it will be much harder to navigate proposed changes that have more contention. Maybe I'm misinterpreting the RFC process, maybe it's only certain people that can say "this needs an RFC"? It's not intended to be a roadblock, just a process (?) |
|
I'm going to close this in favor of the associated RFC, but we can certainly reopen if it's accepted! |
alexcrichton
added
the
B-RFC-approved
|
Turning this into the tracking issue for rust-lang/rfcs#1119 @thepowersgang could you update this PR with a test as well exercising |
|
Test added and pushed, fixed merge errors (and running local test for that now) |
|
All done, probably needs collating into one commit. |
|
Looks good to me! A few small stylistic nits and a squash and this is good to go! |
|
All good for someone to merge and squash? (Or would you prefer I squash it first, not sure how that would affect the comment threads) |
|
Thanks! Could you do the squash yourself? That way we just mark this with |
thepowersgang
force-pushed
the
result-expect-2
branch
from
dd9981b to
090aa91
Compare
|
Manually squashed commits, should be all good (I hope) |
|
@bors: r+ 090aa91d44582f03b9eab9f9f2684e0c78751721 Thanks! |
|
⌛ Testing commit 090aa91 with merge b6a8e79... |
|
💔 Test failed - auto-mac-64-nopt-t |
thepowersgang
force-pushed
the
result-expect-2
branch
from
090aa91 to
0937c10
Compare
|
Updated commit with fixed doc comment |
|
@bors r=alexcrichton |
|
📌 Commit 0937c10 has been approved by |
As it says in the title. I've added an `expect` method to `Result` that allows printing both an error message (e.g. what operation was attempted), and the error value. This is separate from the `unwrap` and `ok().expect("message")` behaviours.
As it says in the title. I've added an
expectmethod toResultthat allows printing both an error message (e.g. what operation was attempted), and the error value. This is separate from theunwrapandok().expect("message")behaviours.