Closed Juan-789 closed 6 months ago
Nice fix! Since we're adding this distinction, we should probably add some error handling in telemetry_utils.py to catch DataBlockUnknownException
s as well.
Also, some github pr conventions that are good to know, your pull request titles should just be a quick blurb about what the PR changes. If you want to auto close issues using "fixes", that should go in the description of the pull request.
I'm not a huge fan of having a dedicated list for not-implemented data blocks, since this will (hopefully) be resolved in the near future as we are implementing them.
In my opinion, I think we can remove the non-implemented list and just try to grab from the subtype dictionary. If subtype
comes back as none, instead of raising a UnknownDataBlock
error, we would raise the not implemented error. This is because the parameter type does say DataBlockSubtype
, so we can assume that only data block subtypes which exist are being passed.
@Juan-789 Are you able to create branches/did I add you to the CarletonURocketry organization? If not lmk, I'll add you so that you can create branches instead of forking
When faced with a known but unimplemented subtype, the program previously raised a DataBlockUnknownException in v1/DataBlock, causing disruptions. Additionally, functions like parse_radio_block in telemetry_utils, dependent on this functionality, failed to raise NotImplemented as intended, leading to further issues. This enhancement ensures a more precise exception handling, resolving both the accuracy of the raise statement and the dependency issues encountered by related functions. I have tested all the subtypes and works for everything except for 00 (debug message) which gives ValueError though I have noticed that it returns this even before i put my hand in so ig everything is fixed