umya-spreadsheet icon indicating copy to clipboard operation
umya-spreadsheet copied to clipboard

structs::numbering_format::NumberingFormat issue

Open CataMark opened this issue 3 years ago • 5 comments

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
}

CataMark avatar Dec 02 '22 20:12 CataMark

Thank you for your report. We will soon release a version that fixes the issues you have pointed out.

MathNya avatar Dec 03 '22 15:12 MathNya

Version 0.8.4, which fixes the problem, has been released.

MathNya avatar Dec 05 '22 02:12 MathNya

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 avatar Jul 02 '25 06:07 fgimian

@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.

MathNya avatar Jul 03 '25 00:07 MathNya

@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!! 😊

fgimian avatar Jul 03 '25 00:07 fgimian