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
There are few major issues with current validation error representation.
Validation on bulk resource creation will not tell which object in whole batch did not pass validation.
Validation of fields with many=True quits on first invalid value and does not allow to find out if all values were incorrect or only few of them. Also if not all, we don't know which ones.
ValueError exceptions are treated equally with ValidationError exceptions. This is great because allows for easier integration with built-in or custom types but on the other hand can leak some implementation details to the user agent. It is equally bad as presenting stack trace to user agent. We should treat ValidationError exceptions as explicit errors that can be safely presented to the user, but ValueError exceptions should be replaced with generic and safe information in type of "Could not parse" or "Invalid format".
The text was updated successfully, but these errors were encountered:
There are few major issues with current validation error representation.
many=True
quits on first invalid value and does not allow to find out if all values were incorrect or only few of them. Also if not all, we don't know which ones.ValueError
exceptions are treated equally withValidationError
exceptions. This is great because allows for easier integration with built-in or custom types but on the other hand can leak some implementation details to the user agent. It is equally bad as presenting stack trace to user agent. We should treatValidationError
exceptions as explicit errors that can be safely presented to the user, butValueError
exceptions should be replaced with generic and safe information in type of "Could not parse" or "Invalid format".The text was updated successfully, but these errors were encountered: