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
If everything is OK (valid JSON that matches schema), everything works well.
However, debugging becomes complicated if something does not match. Sometimes, it's possible to guess what's wrong, but explicit detail would be good.
Here is a simple example that I used to test the package:
class SourceSystem(enum.Enum):
CVX = "CVXA"
@dataclass_json(letter_case=LetterCase.CAMEL, undefined=Undefined.EXCLUDE)
@dataclass
class Match(DataClassJsonMixin):
source_sub_system: SourceSystem
@dataclass_json(letter_case=LetterCase.CAMEL, undefined=Undefined.EXCLUDE)
@dataclass
class Match(DataClassJsonMixin):
source_sub_system: SourceSystem
p = Match.from_dict({ "sourceSubSystem": "CVX"})
Behavior is simple and understandable:
Traceback (most recent call last):
File "match.py", line 112, in <module>
p = Match.from_dict(D)
^^^^^^^^^^^^^^^^^^
File "dataclasses_json/api.py", line 70, in from_dict
return _decode_dataclass(cls, kvs, infer_missing)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "dataclasses_json/core.py", line 233, in _decode_dataclass
init_kwargs[field.name] = _decode_generic(field_type,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "dataclasses_json/core.py", line 296, in _decode_generic
res = type_(value)
^^^^^^^^^^^^
File "enum.py", line 757, in __call__
return cls.__new__(cls, value)
^^^^^^^^^^^^^^^^^^^^^^^
File "enum.py", line 1171, in __new__
raise ve_exc
ValueError: 'CVX' is not a valid SourceSystem
However, there needs to be more information on what field is parsing during this exception.
It can significantly simplify debugging and bug analysis, especially if JSON is received from an external source and you can't control schema like reverse engineering.
Possible solution
Wrap exception during serializer into some Validate Exception that includes caused exception and field name.
Also, it's possible to use chain exception, but it can be unsupported by bug collection tools.
As a more advanced solution, exceptions can be collected and raised as an exception group.
Alternatives
Try to add a field name to the existing exception instance.
Context
No response
The text was updated successfully, but these errors were encountered:
Description
If everything is OK (valid JSON that matches schema), everything works well.
However, debugging becomes complicated if something does not match. Sometimes, it's possible to guess what's wrong, but explicit detail would be good.
Here is a simple example that I used to test the package:
Behavior is simple and understandable:
However, there needs to be more information on what field is parsing during this exception.
It can significantly simplify debugging and bug analysis, especially if JSON is received from an external source and you can't control schema like reverse engineering.
Possible solution
Wrap exception during serializer into some
Validate Exception
that includes caused exception and field name.Also, it's possible to use chain exception, but it can be unsupported by bug collection tools.
As a more advanced solution, exceptions can be collected and raised as an exception group.
Alternatives
Try to add a field name to the existing exception instance.
Context
No response
The text was updated successfully, but these errors were encountered: