I'm using a Cursor to read from an in-memory buffer using Package::open, but found this will err in WASM:
$core::option::expect_failed::ha758e0d1c5165b94 | @ | 50b8976……odule.wasm:0x13208b
$<std::time::SystemTime as core::ops::arith::Sub<core::time::Duration>>::sub::h47beefa3c5880621 | @ | 50b8976……odule.wasm:0x10eb9f
$msi::internal::time::filetime_epoch::h319c0984523cb136 | @ | 50b8976….module.wasm:0xf287e
$msi::internal::time::system_time_from_filetime::hb7b59f8afe76e03c | @ | 50b8976….module.wasm:0xbada6
$msi::internal::propset::PropertyValue::read::h8911128289f30e53 | @ | 50b8976….module.wasm:0x3783e
$msi::internal::propset::PropertySet::read::h221599500522a80f | @ | 50b8976….module.wasm:0x2541b
$msi::internal::summary::SummaryInfo::read::hff04ecde0b584c9d | @ | 50b8976….module.wasm:0x4fce8
$msi::internal::package::Package<F>::open::h20cfea195083e72b
While the source of the error is no doubt the constraints of the environment under which the code is running, it would be nice if certain errors might be skipped. There is no date-time that must be read from a \005SummaryInformation stream.
To note, this only fails in WASM I've found. I have separated functions to test locally like so:
#[wasm_bindgen(js_name = "getProductInfo")]
pub fn get_product_info(data: &[u8]) -> Result<ProductInfo, JsValue> {
let cursor = Cursor::new(data);
console_log!("opening package from {} bytes", data.len());
let info = read_product_info(cursor).unwrap_throw();
Ok(info)
}
pub fn read_product_info<R>(data: R) -> Result<ProductInfo, Box<dyn Error + Send + Sync>>
where
R: Read + Seek,
{
let mut package = Package::open(data)?;
// ...
}Calling read_product_info locally works fine. This is just for context, though; again, I realize the source of the underlying problem isn't here: I'm just questioning whether failing to read some data should be strictly fatal.
I'm using a
Cursorto read from an in-memory buffer usingPackage::open, but found this will err in WASM:While the source of the error is no doubt the constraints of the environment under which the code is running, it would be nice if certain errors might be skipped. There is no date-time that must be read from a
\005SummaryInformationstream.To note, this only fails in WASM I've found. I have separated functions to test locally like so:
Calling
read_product_infolocally works fine. This is just for context, though; again, I realize the source of the underlying problem isn't here: I'm just questioning whether failing to read some data should be strictly fatal.