Errors format is too complex
See original GitHub issueHi,
I would like to discuss errors format, to my mind it’s too complex to understand and parse for now.
- Let’s start from something simple
class Test(BaseModel):
k_str: constr(min_length=42)
k_int: int
Test(k_str='min')
1.1 Error codes only
{
"k_str": "min_length",
"k_int": "required",
}
1.2 Error codes + human readable messages
{
"k_str": {
"error_code": "min_length",
"error_message": "...",
},
"k_int": {
"error_code": "required",
"error_message": "...",
},
}
I prefer variant 1.1 and in all examples below I will use it.
- Recursive models
class Foo(BaseModel):
count: int
class Bar(BaseModel):
uid: uuid.UUID
class Spam(BaseModel):
foo: Foo
bars: List[Bar]
Spam.parse_obj({
'bars': [
uuid.uuid4(),
'not_uuid',
],
})
2.1 Error codes only
{
"foo": {
"count": "required",
},
"bars": {
1: {
"uid": "invalid",
},
},
}
Some points about format:
- We need
error_code
to have ability easily write error parsers, it’s very useful for APIs and documentation. We can extend error codes and add more context, e.g.:min_length:42
where42
is required minimum. - We need
error_message
in some cases for humans, but I don’t think that you wound like to think about localization… Also I think any developer can build their own human readable messages using error codes only. - I don’t think that we need to return list of errors for one type, let’s return first one. It’s more easily to implement and support and it’s better for performance reasons.
- Do not use
track
attr for recursive models, it’s complex to parse. Let’s use tree logic and dictionaries can help us with this. Lists can be represents as dictionaries too, just use element index as key. - Using my proposal you can easily convert errors dictionary to something else e.g. to JSONPoiters https://tools.ietf.org/html/rfc6901.
- This format isn’t my idea, something very similar used in Cerberus.
I know that changes like this are backward incompatible, so let’s discuss and let me know if you need more detailed examples. Also I can try to implement proof of concept and send PR to you.
Issue Analytics
- State:
- Created 5 years ago
- Comments:19 (19 by maintainers)
Top Results From Across the Web
Errors format is too complex · Issue #162 · pydantic ... - GitHub
Hi, I would like to discuss errors format, to my mind it's too complex to understand and parse for now. Let's start from...
Read more >Function is too complex (C901) - Flake8 Rules
Functions that are deemed too complex are functions that have too much branching logic. Branching logic includes if/elif/else and for/while loops.
Read more >Expression is too complex or statement is too long. (4384)
Expression is too complex or statement is too long. ... In OpenEdge 11.x, compile or syntax check fails with error (4384) ... Files(0)....
Read more >Solved: Page too complex - HP2600n laserjet - HP Community
basically it seems when the “page too complex” it's just dead . ... A job to complex error suggests an issue with the...
Read more >Expression is too complex to be evaluated - Date Problem ...
This expression is typed incorrectly, or it is too complex to be evaluated. For example, a numeric expression may contain too many complicated...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
New error format is implemented, so I’m going to close this issue. All other improvements better to do in separate issues or pull requests.
Let’s try gitter!