You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We felt that unreachable!() better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to panic!(), which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib).
However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code.
Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to unreachable!(). It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since unreachable!() still includes a filename and line number in its output.
However, given the precedent of optional messages set by panic!(), I don't think it would be a stretch to imagine that unreachable!() could also have an optional message. Usage for the typical case would be the same:
unreachable!("bamboozled the frobnob");// task '<main>' panicked at 'internal error: entered unreachable code: bamboozled the frobnob', unreachable.rs:2
The text was updated successfully, but these errors were encountered:
bstrie
changed the title
Add an option string parameter to the unreachable!() macro to communicate which invariant was violated
Add an optional string parameter to the unreachable!() macro to communicate which invariant was violated
Nov 10, 2014
bstrie
added
P-low
Low priority
E-easy
Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
labels
Nov 10, 2014
In #18287 we had the submitter change a
panic!()
to anunreachable!()
as follows:We felt that
unreachable!()
better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed topanic!()
, which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib).However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code.
Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to
unreachable!()
. It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, sinceunreachable!()
still includes a filename and line number in its output.However, given the precedent of optional messages set by
panic!()
, I don't think it would be a stretch to imagine thatunreachable!()
could also have an optional message. Usage for the typical case would be the same:...but could optionally look like this:
The text was updated successfully, but these errors were encountered: