Skip to content

Commit dfb37cb

Browse files
committed
Add section on common message styles for Result::expect
1 parent 34a6c9f commit dfb37cb

File tree

1 file changed

+56
-0
lines changed

1 file changed

+56
-0
lines changed

library/core/src/result.rs

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1023,6 +1023,62 @@ impl<T, E> Result<T, E> {
10231023
/// let x: Result<u32, &str> = Err("emergency failure");
10241024
/// x.expect("Testing expect"); // panics with `Testing expect: emergency failure`
10251025
/// ```
1026+
///
1027+
/// # Common Message Styles
1028+
///
1029+
/// There are two common styles for how people word `expect` messages. Using the message to
1030+
/// present information to users encountering a panic ("expect as error message") or using the
1031+
/// message to present information to developers debugging the panic ("expect as
1032+
/// precondition").
1033+
///
1034+
/// In the former case the expect message is used to describe the error that has occurred which
1035+
/// is considered a bug. Consider the following example:
1036+
///
1037+
/// ```
1038+
/// // Read environment variable, panic if it is not present
1039+
/// let path = std::env::var("IMPORTANT_PATH").unwrap();
1040+
/// ```
1041+
///
1042+
/// In the "expect as error message" style we would use expect to describe that the environment
1043+
/// variable was not set when it should have been:
1044+
///
1045+
/// ```
1046+
/// let path = std::env::var("IMPORTANT_PATH")
1047+
/// .expect("env variable `IMPORTANT_PATH` is not set");
1048+
/// ```
1049+
///
1050+
/// In the latter style, we would instead describe the reason we _expect_ the `Result` will
1051+
/// always be `Ok`. With this style we would instead write:
1052+
///
1053+
/// ```
1054+
/// let path = std::env::var("IMPORTANT_PATH")
1055+
/// .expect("env variable `IMPORTANT_PATH` is always be set by `wrapper_script.sh`");
1056+
/// ```
1057+
///
1058+
/// The "expect as error message" style has the advantage of giving a more user friendly error
1059+
/// message, and is more consistent with the default output of the [panic hook] provided by
1060+
/// `std`.
1061+
///
1062+
/// ```
1063+
/// thread 'expect_as_error_message' panicked at 'env variable `IMPORTANT_PATH` is not set: NotPresent', src/lib.rs:4:10
1064+
/// ```
1065+
///
1066+
/// The "expect as precondition" style instead focuses on source code readability, making it
1067+
/// easier to understand what must have gone wrong in situations where panics are being used to
1068+
/// represent bugs exclusively. But this extra information often looks confusing when presented
1069+
/// directly to users with the default `std` panic hook's report format:
1070+
///
1071+
/// ```
1072+
/// thread 'expect_as_precondition' panicked at 'env variable `IMPORTANT_PATH` is always set by `wrapper_script.sh`: NotPresent', src/lib.rs:4:10
1073+
/// ```
1074+
///
1075+
/// This style works best when paired with a custom [panic hook] like the one provided by the
1076+
/// CLI working group library, [`human-panic`], which redirects panic messages to crash report
1077+
/// files while showing users a more "Oops, something went wrong!" message with a suggestion to
1078+
/// send the crash report file back to the developers.
1079+
///
1080+
/// [panic hook]: https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html
1081+
/// [`human-panic`]: https://docs.rs/human-panic
10261082
#[inline]
10271083
#[track_caller]
10281084
#[stable(feature = "result_expect", since = "1.4.0")]

0 commit comments

Comments
 (0)