Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

29979: Removed the use of expect from CodingStandardsRust #883

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
@@ -256,20 +256,20 @@ 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 {
u16::from_str_radix(config_string, 10).unwrap()
}

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):