This repository contains code and data for testing the compliance of Automated Frequency Coordinator (AFC) software. The AFC is defined by the FCC in proceeding 18-295 on Unlicensed Use of the 6 GHz Band. This repository contains procedures, documentation, and tests for such software, and for the devices authorized by it. To contribute, please first read the CONTRIBUTING file in the repository for instructions.
14
stars
3
forks
source link
Improve warning messages on object conversion failure #26
Resolves #18 by clarifying messages related to dataclass conversion in validator paths. This PR does not use either of the methods proposed in #18 for reasons discussed below:
Selective removal of the suppress(Error) wrappers for "critical" sub-fields would allow the error to propagate upwards and trigger the except clause in test_main.py. However, this would also prevent the partial initialization of any parent object, which is not desired by other code (i.e., the validators).
As noted, removal of the suppress wrappers prevents the validators from logging any other issues with a given object. After testing, this was confirmed to be undesirable.
An alternate fix may be to explicitly validate the presence of the dataclass version of the provided and accessed objects in response_mask_runner.py to ensure field-access errors (using dot-notation to access fields of dicts, etc.) are avoided, and the root issue (failure to create the dataclass representation) is reported clearly.
This approach is unwieldy, as it would require a type-check before the first access of each subfield (including nested subfields, of which there are many).
I also considered adding an explicit recursive type-check in test_main after converting the response JSON to object form, external to the validator. However, this causes the test to be skipped for issues in non-critical fields (like VendorExtensions).
The most comprehensive solution to #18 is likely a combination of the "alternate" fix and the recursive type-checker, implemented by using some hidden class variables identifying "required" fields for iteration over by an explicit type checker. If this PR is not sufficient to alleviate the concerns in #18, I recommend pursuing this option.
Resolves #18 by clarifying messages related to dataclass conversion in validator paths. This PR does not use either of the methods proposed in #18 for reasons discussed below:
I also considered adding an explicit recursive type-check in test_main after converting the response JSON to object form, external to the validator. However, this causes the test to be skipped for issues in non-critical fields (like VendorExtensions).
The most comprehensive solution to #18 is likely a combination of the "alternate" fix and the recursive type-checker, implemented by using some hidden class variables identifying "required" fields for iteration over by an explicit type checker. If this PR is not sufficient to alleviate the concerns in #18, I recommend pursuing this option.