Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Empty except clauses are code smell](https://stackoverflow.com/questions/14797375/should-i-always-specify-an-exception-type-in-except-statements/). At the very least, they can unintentionally catch KeyboardInterrupt and SystemExit exceptions. At worse, they can hide bugs. Looking through Buildozer code, there are four empty except clauses in `android.py`. One protects a call to set_win32_java_home() (on Windows machines), Given win32 isn't yet supported, this is moot, but there doesn't seem to be a justification for ignoring exceptions in this scenario - if setting the home fails, Buildozer should fail. Deleted try block. One protects a parse of the app version number. The called code already catches the most obvious exception (a badly-formatted version number). There don't seem to be any other expected exceptions, so there is not reason to swallow this exception. Deleted try block. One is harder to understand. After calling `execute_built_package()`, a try block attempts to call it **again**, surrounded by calls to run a pre-build and post-build hook on buildozer. However, the hook is never defined anywhere. This always dies with an `AttributeError` which is swallowed and ignore by the empty exception block, without the duplicate call to build. I am guessing it is a carry-over from an attempt to make Buildozer support hooks. This is an example of why not to use empty Exception blocks! Removed the try block and the protected code. The fourth example protects an attempt to decode Unicode. `content` is read from a IO object opened in 'r' mode, so it will always be a `str` and will never have a `decode()` attribute, so this will always fail. Removed the code in the try block and just kept the except: part.
- Loading branch information