In #1439 it became clear that there are a lot of cases where there is a TypeAdaptor validation in the codebase.
To ensure the resulting ValidationErrors are properly caught and re-raised with a dedicated error message, we should:
- create 2 wrappers which accept a TypeAdaptor object as the first object, the object to validate as the second argument....
- the first one would also a custom error class and custom error message as additional arguments. The wrapper will ensure all ValidationErrors are re-raised properly with custom errors
- the second one would have a third argument giving the default return value for what to do on a validation error.
- ban the
TypeAdaptor.validate_python API via ruff config; inline ignore the violation for the two wrappers' use of it.
- Work through the ruff violations and replace them with the safe wrapper.
We should document the rationale - we want to ensure that all ValidationErrors are handled and do not propogate.
In #1439 it became clear that there are a lot of cases where there is a
TypeAdaptorvalidation in the codebase.To ensure the resulting
ValidationErrorsare properly caught and re-raised with a dedicated error message, we should:TypeAdaptor.validate_pythonAPI via ruff config; inline ignore the violation for the two wrappers' use of it.We should document the rationale - we want to ensure that all
ValidationErrorsare handled and do not propogate.