You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In hgettoken.py the fatal() function prints a message before halting execution with a non-zero exit code (via sys.exit), is there any objection to (me) refactoring calls to this function to instead raise standard Python exception types?
The impact on the standard command-line execution would be that a traceback is printed (currently that is not printed).
IMO, this will greatly assist the planned Python interface by providing an interface for users to catch exceptions and handle them in a bespoke manner.
The text was updated successfully, but these errors were encountered:
I'd rather not have the traceback in the command line, but couldn't that be eliminated by putting a try/except in main()? Oh, but I think it would be a problem in cases where it is already in a try/except block. Right?
Yes; if the idea is to not have long tracebacks for command-line execution, this can be handled in main() or in the if __name__ == "__main__" blocks. I'll try and put something together. Thanks Dave.
In
hgettoken.py
thefatal()
function prints a message before halting execution with a non-zero exit code (viasys.exit
), is there any objection to (me) refactoring calls to this function to insteadraise
standard Python exception types?The impact on the standard command-line execution would be that a traceback is printed (currently that is not printed).
IMO, this will greatly assist the planned Python interface by providing an interface for users to catch exceptions and handle them in a bespoke manner.
The text was updated successfully, but these errors were encountered: