structs::numbering_format::NumberingFormat issue
The following panics by default:
pub fn set_number_format_id(&mut self, value: u32) -> &mut Self {
self.format_code = FILL_BUILT_IN_FORMAT_CODES
.iter()
.find_map(|(key, val)| {
if key == &value {
Some(val.clone())
} else {
panic!("Not Found NumberFormatId.") //this line should be None
}
})
.unwrap();
self.number_format_id = value;
self.is_build_in = true;
self
}
Thank you for your report. We will soon release a version that fixes the issues you have pointed out.
Version 0.8.4, which fixes the problem, has been released.
I just got bitted by this one. The current implementation is still not quite ideal as it still panics.
pub fn set_number_format_id(&mut self, value: u32) -> &mut Self {
let format_code_result = FILL_BUILT_IN_FORMAT_CODES.iter().find_map(|(key, val)| {
if key == &value {
Some(val.clone())
} else {
None
}
});
self.format_code = format_code_result
.expect("Not Found NumberFormatId.")
.into_boxed_str();
self.number_format_id = value;
self.is_build_in = true;
self
}
Rust is a language that is all about runtime safety. If something can fail, then the function really should return a Result. I highly suggest the following in your Cargo.toml:
[lints.clippy]
expect_used = "warn"
unwrap_used = "warn"
Ideally unwrap or expect should only ever be used in a library when there is no chance at all that something can fail.
Cheers Fotis
@fgimian Thank you for contacting us. We will consider responding to this issue in version 3.0 or later, as the scope of impact is likely to be larger.
@fgimian Thank you for contacting us. We will consider responding to this issue in version 3.0 or later, as the scope of impact is likely to be larger.
Awesome, thanks so much for all your hard work on this library!! 😊