-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve custom error handling. #42
base: master
Are you sure you want to change the base?
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. |
@@ -1,5 +1,36 @@ | |||
__version__ = '0.3.0' | |||
|
|||
error_messages = { | |||
'did not validate': '{schema} {reason} {data}', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.