enhance code generator error reporting

[pljakobs]

code generator currently relies on the python traceback to provide insight on failure of compiling the schema.
It would be good to at least see the offending schema line to be able to more easily correct issues.

CFGDB app-config.cfgdb app-data.cfgdb defs.cfgdb
Parsing app-config ...
Parsing app-data ...
Parsing defs ...
Traceback (most recent call last):
  File "/home/pjakobs/devel/esp_rgbww_firmware/Components/ConfigDB/tools/dbgen.py", line 1406, in <module>
    main()
  File "/home/pjakobs/devel/esp_rgbww_firmware/Components/ConfigDB/tools/dbgen.py", line 1395, in main
    parse_database(db)
  File "/home/pjakobs/devel/esp_rgbww_firmware/Components/ConfigDB/tools/dbgen.py", line 679, in parse_database
    parse_properties(root, database.schema['properties'])
                           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
KeyError: 'properties'
make: *** [/home/pjakobs/devel/esp_rgbww_firmware/Components/ConfigDB/component.mk:25: /home/pjakobs/devel/esp_rgbww_firmware/out/ConfigDB/app-config.h] Fehler 1

[mikee47]

Agree this would be helpful. I note that JSON formatting errors already do this, but that's a feature of the python JSON decoder.

It would be nice if errors like the one above could be caught by the schema validator, since properties isn't optional here. The code generator runs the schema through though a Draft7Validator but don't think its ever actually caught anything! Maybe some kind of custom schema to validate the .cfgdb schema would help.

I can't see any direct way to associate line numbers with decoded JSON, but it would be fairly straightforward to track and print the parsing location as a JSON pointer (e.g. basic_config/properties/channels/items/properties/pin/default)

[mikee47]

Some improvements in #57, perhaps this will suffice?

[pljakobs]

I've seen a useful error while building with the external schema change, have not tried it with deliberately broken schema definitions.

[pljakobs]

I found another place where error handling could be a bit better:

        "clear_pin":{
          "type":"integer",
          "default":-1
        },

I had, mistakenly, put quote marks around the default value, making it a string. The error message from dbgen.py was

TypeError("'<=' not supported between instances of 'int' and 'str'")

If I'm not wrong, this error came from here:

@dataclass
class Range:
    minimum: int | float
    maximum: int | float

    def check(self, value: int | float | list):
        if isinstance(value, list):
            for v in value:
                self.check(v)
            return
        if self.minimum <= value <= self.maximum:
            return
        raise ValueError(f'Value {value} outside range {self.minimum} <= value <= {self.maximum}')

which makes sense if the default value is read as a string. However, I think it would be more user friendly to directly catch the fact that the default is not matching the described data type.

[mikee47]

... However, I think it would be more user friendly to directly catch the fact that the default is not matching the described data type.

Looks like the schema checker doesn't do much for default values, though it does catch some errors with other fields such as "maximum": "100":

'100' is not of type 'number' @ deque(['properties', 'simple-int', 'maximum'])

It doesn't differentiate between float and int though so probably worth doing our own checks for that. Also need to add extra parsing for array defaults so each item is of the correct type.