Merge branch 'pr_883_squashed'

This commit is contained in:
Nick Mathewson 2019-04-03 08:32:21 -04:00
commit b547ece92f

View File

@ -256,7 +256,7 @@ Here are some additional bits of advice and rules:
or 2) should fail (i.e. in a unittest). or 2) should fail (i.e. in a unittest).
You SHOULD NOT use `unwrap()` anywhere in which it is possible to handle the 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: For example, consider a function which parses a string into an integer:
fn parse_port_number(config_string: &str) -> u16 { 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 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`) (or another equivalent function which will return an `Option` or a `Result`)
and change the return type to be compatible: and change the return type to be compatible:
fn parse_port_number(config_string: &str) -> Option<u16> { 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): or you SHOULD use `or()` (or another similar method):