commit 0ebe290198ca852c27422fb3a82670f113f78727 Author: Elichai Turkel elichai.turkel@gmail.com Date: Mon Apr 1 21:50:02 2019 +0300
Removed the use of expect from CodingStandardsRust --- doc/HACKING/CodingStandardsRust.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/HACKING/CodingStandardsRust.md b/doc/HACKING/CodingStandardsRust.md index fc562816d..b570e10dc 100644 --- a/doc/HACKING/CodingStandardsRust.md +++ b/doc/HACKING/CodingStandardsRust.md @@ -256,7 +256,7 @@ Here are some additional bits of advice and rules: or 2) should fail (i.e. in a unittest).
You SHOULD NOT use `unwrap()` anywhere in which it is possible to handle the - potential error with either `expect()` or the eel operator, `?`. + potential error with the eel operator, `?` or another non panicking way. For example, consider a function which parses a string into an integer:
fn parse_port_number(config_string: &str) -> u16 { @@ -264,12 +264,12 @@ Here are some additional bits of advice and rules: }
There are numerous ways this can fail, and the `unwrap()` will cause the - whole program to byte the dust! Instead, either you SHOULD use `expect()` + whole program to byte the dust! Instead, either you SHOULD use `ok()` (or another equivalent function which will return an `Option` or a `Result`) and change the return type to be compatible:
fn parse_port_number(config_string: &str) -> Option<u16> { - u16::from_str_radix(config_string, 10).expect("Couldn't parse port into a u16") + u16::from_str_radix(config_string, 10).ok() }
or you SHOULD use `or()` (or another similar method):