You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This line bit me a few times yesterday. Modules are supposed to encode their vendor name and other string-like data using ASCII. Some of the cheaper OEM modules we're using don't always do that, which leads to a panic when we unwrap in that linked line. There are other places too, such as the DateCode conversions, where we interpret the bytes and possibly unwrap.
This all needs to change somewhat. It's unfortunate to panic on these kinds of things, and we should probably return an error instead. Better yet, we can change the way these decoders work -- they should just take one or more byte arrays, and include accessor functions which try to decode the relevant slices of data, returning an error if that fails. We can include methods that return a default or "unknown" value as well, if that's useful.
The text was updated successfully, but these errors were encountered:
This line bit me a few times yesterday. Modules are supposed to encode their vendor name and other string-like data using ASCII. Some of the cheaper OEM modules we're using don't always do that, which leads to a panic when we unwrap in that linked line. There are other places too, such as the
DateCode
conversions, where we interpret the bytes and possibly unwrap.This all needs to change somewhat. It's unfortunate to panic on these kinds of things, and we should probably return an error instead. Better yet, we can change the way these decoders work -- they should just take one or more byte arrays, and include accessor functions which try to decode the relevant slices of data, returning an error if that fails. We can include methods that return a default or "unknown" value as well, if that's useful.
The text was updated successfully, but these errors were encountered: