Conversation
The Schema 'error' kwarg now supports a callable, which returns the error message as a string. Its arguments are:
- schema: the underlying schema object
- data: the data being validated
- reason: a string constant for the type of error encountered
- details: further details about the reason for the failure. may be an exeption, a string, or None
Additionally, error strings passed to the Schema 'error' kwarg are now provided more context about the error in the form of four {fields} for use with "new-style" string formatting. These are string representations of the four arguments described above.
|
One design decision that I've been wavering on is whether the def auto_error(schema, data, reason, details):
return 'Error encountered with {data!r}'.format(data=data)or if it should take a dictionary so that it will be easier to add more context items later without breaking existing error handlers: def auto_error(context):
return 'Error encountered with {data!r}'.format(**context) |
|
I just noticed the doctest is failing on Travis. The reason for the error is that inside the new if callable(schema) and hasattr(schema, '__name__'):
schema = schema.__name__
else:
schema = repr(schema)This means that errors that used to look like this: Now look like this: Personally, I prefer the latter, but if you don't want to make this change, I can modify the stringification of callables to only use if inspect.isfunction(schema) and hasattr(schema, '__name__'):
schema = schema.__name__
else:
schema = repr(schema)Let me know what you prefer. |
There was a problem hiding this comment.
I feel like these should be different subclasses of SchemaError. Then we could catch them selectively with try/except in calling code. What do you think?
There was a problem hiding this comment.
I think that I made this pull request over a year ago and it's obvious that this project is not actively maintained. I've moved on. schemtatics looks interesting....
The
Schema'error' kwarg now supports a callable, which returns the error message as a string. Its arguments are:schema: the underlying schema objectdata: the data being validatedreason: a string constant for the type of error encountereddetails: further details about the reason for the failure. may be an exeption, a string, or NoneAdditionally, error strings passed to the
Schema'error' kwarg are now provided more context about the error in the form of four{fields}for use with "new-style" string formatting. These are string representations of the four arguments described above.