Skip to content

Create a safer abstraction for TypeAdapter validation #1440

@nathanjmcdougall

Description

@nathanjmcdougall

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.

Metadata

Metadata

Labels

internalChanges to the internals without changing interfaces

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions