-
Notifications
You must be signed in to change notification settings - Fork 2
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
Draft: error handling in autoreporting tool #70
Conversation
Scripts/gws_fetch.py
Outdated
except KeyError: | ||
cols=list(df.columns) | ||
columns_not_in_cols=[a for a in columns.values() if a not in cols] | ||
print("A KeyError happened while parsing the input file {}. It is likely that the columns given to the script do not match with actual input file columns.".format(fname)) |
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.
you can explicitly check that and give the exact column not in the data.
Scripts/main.py
Outdated
except Exception as e: | ||
print("Exception occurred. Check the above errors. The tool will now abort.") | ||
fname=die() | ||
print("Traceback printed in file {}".format(fname)) |
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.
might be good to start using actual logger package (https://docs.python.org/3/library/logging.html) ... it would be easier to control what level of logging goes where. Also keeping in mind usage of this in pipelining... now we would miss the stacktrace when running via WDL or if we add that to WDL output, we error out as the file might not exist. logging package would allow different configuration options depending on running mode.
make that annotation file required in argparse if it's expected.....
|
Here's a try at using the There's quite a lot of merge conflicts but those are fairly straightforward to clear, mainly due to code changing in similar places. |
This PR is a draft for how handling could be.
The basic idea is that users do not want to see stack traces, so they aren't printed when the script errors out. Instead, human-readable explanation is printed to stdout where it is possible (aka where the correct variables are available), and the stack trace is printed to a file (and/or stderr?). A return code of 1 will be sent in case of any error, and 0 in case of no errors.
I'd be happy to hear if this sounds sensible, and if there are other possible ways that might be more suitable.
also aims to fix #68