Skip to content
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 error reporting #209

Closed
lassoan opened this issue Oct 24, 2023 · 6 comments
Closed

Improve error reporting #209

lassoan opened this issue Oct 24, 2023 · 6 comments

Comments

@lassoan
Copy link
Contributor

lassoan commented Oct 24, 2023

While working on fixing some issues related to setting license files (#208), I've noticed that errors are not handled very consistently throughout the code base. It would be nice to consistently use exceptions for reporting errors from functions.

Currently, some places exit() is called to signal errors. This is not good because it makes it impossible to call the Python function from an application, because calling exit() immedately crashes the entire application.

At some other places, complex return values are used. For example, error code and error text. This is not ideal either, because it makes the code too complicated and fragile (you need to make sure that the list items that are returned matches the expected list items everywhere where the function is used).

Instead, you can define your own exception type that stores everything that you need, such error code, text displayable to the user. The exception can be caught in the executable scripts or you can just let Python's default exception handler deal with the issue (print the stack trace and quit the process with error status).

@wasserth
Copy link
Owner

Thanks for your pull request.
I agree that the error handling can be improved.
I can use a (custom) exception and then catch it to show the error message (I do not want to show the entire stack trace to a user who only entered a wrong license number). But then I would also have to do exit() to stop the program at this point. Otherwise I would have to add a lot of if/else to make the sure in any case the control flow does not continue. This is a lot easier with exit(). Or do you have another idea how to replace exit() and still exit the programm at certain points without showing a stack trace?

@lassoan
Copy link
Contributor Author

lassoan commented Oct 24, 2023

Yes, what you describe sounds good. I agree that in the executable Python script it is nicer to catch the exception and print just an error message (and not use the default exception handler that prints the stack trace).

Otherwise I would have to add a lot of if/else to make the sure in any case the control flow does not continue. This is a lot easier with exit(). Or do you have another idea how to replace exit() and still exit the programm at certain points without showing a stack trace?

You don't need to use exit to break the flow, you can use raise YourException(...) instead.

@wasserth
Copy link
Owner

Is it possible to build a custom exception which I can raise, but which does not print the stack trace when raising it? I did some testing but did not manage to built such a exception.

@lassoan
Copy link
Contributor Author

lassoan commented Oct 24, 2023

You only get a stack trace if you don't catch the exception and it is caught by the default exception handler. If you catch the exception in your main function and print the message and exit then no stack trace will be printed.

@wasserth
Copy link
Owner

That is correct. I only wonder how I can exit after catching the exception without calling sys.exit()? If I understand you correctly you want to avoid using sys.exit().

@lassoan
Copy link
Contributor Author

lassoan commented Oct 24, 2023

Calling sys.exit() in the executable script (such as totalseg_set_license.py) is no problem at all, because that is always executed in a separate process. Calling it in the Python API, such as in libs.py is a problem, because I may want to use the Python API in an application that I don't want to crash when some error happens.

To be safe, you can completely avoid exit() and just use return from the main function.

@wasserth wasserth closed this as completed Aug 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants