@@ -1023,6 +1023,62 @@ impl<T, E> Result<T, E> {
1023
1023
/// let x: Result<u32, &str> = Err("emergency failure");
1024
1024
/// x.expect("Testing expect"); // panics with `Testing expect: emergency failure`
1025
1025
/// ```
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
1026
1082
#[ inline]
1027
1083
#[ track_caller]
1028
1084
#[ stable( feature = "result_expect" , since = "1.4.0" ) ]
0 commit comments