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
Currently, validators/constructors/converters can raise arbitrary exceptions, which are then converted to ValidationError.
This is a security concern, as it could leak implementation details if unwanted exceptions are not properly catched — let's imagine a validator using database, and leaking connection information if this one is temporarily unreachable. This behavior must be deprecated.
Deprecation should also act as breaking change, with a simple way to get back the old behavior, for example a settings key with a deprecation warning.
However, raising a ValidationError is not convenient today, because it's constructor doesn't accept a simple error message string. Constructor should therefore be overloaded.
Also, validators could take a new parameter describing exceptions allowed to be raised in the validator, which would be then converted to ValidationError.
The text was updated successfully, but these errors were encountered:
Deprecation should also act as breaking change, with a simple way to get back the old behavior, for example a settings key with a deprecation warning.
Finally, no simple way has been added, this is a complete breaking change.
Also, validators could take a new parameter describing exceptions allowed to be raised in the validator, which would be then converted to ValidationError.
As written in the documentation, this completely useless, because a simple decorator can do the job.
Currently, validators/constructors/converters can raise arbitrary exceptions, which are then converted to
ValidationError
.This is a security concern, as it could leak implementation details if unwanted exceptions are not properly catched — let's imagine a validator using database, and leaking connection information if this one is temporarily unreachable. This behavior must be deprecated.
Deprecation should also act as breaking change, with a simple way to get back the old behavior, for example a settings key with a deprecation warning.
However, raising a
ValidationError
is not convenient today, because it's constructor doesn't accept a simple error message string. Constructor should therefore be overloaded.Also, validators could take a new parameter describing exceptions allowed to be raised in the validator, which would be then converted to
ValidationError
.The text was updated successfully, but these errors were encountered: