-
Notifications
You must be signed in to change notification settings - Fork 166
Add custom validator to blueprint variables #218
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
Conversation
- Now all blueprint variables must provide a `type`, otherwise an exception is thrown. Before it wasn't required, and the type was ignored if it wasn't provided. That didn't seem right to me, but I realize I may just not have understood the implications. Other changes: - variable resolution now done in a function not a class method - moved variable type validation to a function - instead of passing the whole blueprint just to use it's name, I just pass the blueprints name into the exceptions that use them (that was all the blueprint was used for it appeared) I'll add docs in the next checkin.
Fixes #217 |
|
||
# If no validator, return the value as is, otherwise apply validator | ||
validator = var_def.get("validator", lambda v: v) | ||
value = validator(value) |
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 we should have a preferred exception that validators raise that gets caught here. Then we can include more details about which variable was invalid etc.
Right now if you raise an exception within the validator, you can't tell which variable was being validated.
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.
or maybe just any exception that is raised by the validator we wrap with some other info?
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.
Good call - I'll think about it and come up with something that makes it easy to tell which variable failed it's validator, and why.
Makes it a bit more explicit when there is an issue with a validator.
try: | ||
value = validator(value) | ||
except Exception as exc: | ||
raise ValidatorError(var_name, validator.__name__, value, exc) |
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.
add this to docstring above
👍 |
|
type
, otherwise anexception is thrown.
Before it wasn't required, and the type was ignored if it wasn't
provided. That didn't seem right to me, but I realize I may just not
have understood the implications.
Other changes:
pass the blueprints name into the exceptions that use them (that was
all the blueprint was used for it appeared)
I'll add docs in the next checkin.