-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add better error handling #70
Comments
The general pattern I'd go with would be to have a base Exception class ( try:
# do all of the schema-enforcer function calls that we're already doing
except SchemaEnforcerException as exc:
error(str(exc))
sys.exit(1) The main benefit of this approach is that it makes it easier in future to use schema-enforcer as a library as part of some other program (without needing to go through the CLI) and the consumer of this library can decide for itself what it wants to do if these various errors are encountered (which may or may not be a |
Brilliant, thank you for the input! I'll work something up :). |
@PhillSimonds would updating of the error message format also be included in this or do I need a new issue for it? Having just numbers such as |
@jvanderaa I think we'll need a new issue for this as the string representing the error wouldn't change per this issue. |
Environment
Proposed Functionality
Schema enforcer currently calls sys.exit(1) after an error occurs, rather than raising an exception which describes the failure case then allowing that exception to bubble up, quitting script execution if it's not handled. This feature request proposes adding custom exceptions (or non-custom exceptions, pending use case) to throw when an issue occurs instead of calling sys.exit().
Use Case
in schema enforcer's SchemaManager class, a test_dir file is verified for existence before schema enforcer iterates over test cases to verify that when data is checked for schema adherence, the validation yields an expected result. The following code block is in use in the function that does this.
When this block of code is hit, the following message is generated
The ERROR message is printed in red, and the output is easy to understand for the user.
This feature proposes rewriting this code block, and others like it, so that a design pattern akin the the following would be used instead
I've not played around with how to suppress the stack trace to give an inteligable message instead of the long variant that can be difficult for users to understand, but think we should attempt to do so in some way/form.
The text was updated successfully, but these errors were encountered: