on_error validator and field property

[samuelcolvin]

• Validator which returns a default value when validation fails
• setting on TypeDict Field which allows the value to be omitted or the default to be used if an error occurs

[PrettyWood]

Hi @samuelcolvin What would be the expected API for this?
I first thought about a new on_error field in TypedDictField with possible values

• {'type': 'raise'}: default
• {'type': 'ignore'}: only valid for not required fields (SchemaError is raised if the field is required)
• {'type': 'default'}
• {'type': 'default_factory'}
• {'type': 'function'}: custom validator (like plain FunctionValidator), which takes the input value

But I guess we could have everything behind a function and avoid this distinction. And I may also miss some usecases

[samuelcolvin]

I could just have just a bool {'ignore_errors': bool}:

• False - current behaviour
• True - whatever we currently do if the value is not included - e.g. default, default_factory, omit; SchemaError if there's no such option.

ignore_errors name is up for debate.

[PrettyWood]

The thing is I've seen some usecases (and pydantic issues) where you would want to log bad values, or put them in some kind of global array or whatever. So calling a function with the bad value could be something useful. And it would allow people to put a different default value for omitted inputs vs wrong inputs

[samuelcolvin]

Yes, but can't we just use existing wrap validators for that?

[PrettyWood]

I see what you mean ok! I'll work on it soon

[samuelcolvin]

maybe we should make it a literal of options as you suggested so it's easier to extend in future?

[PrettyWood]

I'll go with a literal for on_error with 3 possible values:

• raise (default value if not set) --> raise a ValidationError if validation fails
• omit (if the field is required raise a SchemaError) --> if the field is optional, it will simply be ignored
• fallback_on_default (if the schema has no default or default_factory raise a SchemaError) --> fallback on default or default_factory

Because there are some usecases where we want to differentiate missing input value (e.g. 0) and wrong input value (e.g. NaN)
And indeed the wrap function works perfectly for any desired fallback 👍 (An example in the doc will probably be needed)

@samuelcolvin are you ok with this? If yes I'll reopen my old PR and change implementation

EDIT: Names can be changed of course but I reckon it's a good idea to allow omitting values on errors even if a default is set