Skip to content

feat: Increase installation logging granularity and set process exit code properly #365

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

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

laur89
Copy link

@laur89 laur89 commented Apr 20, 2025

No description provided.

@oSumAtrIX oSumAtrIX changed the base branch from main to dev April 20, 2025 18:00
@@ -44,20 +45,35 @@ internal object InstallCommand : Runnable {
}.install(Installer.Apk(apk, packageName))
} catch (e: Exception) {
logger.severe(e.toString())
throw e
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we logging when throwing the exception which will be logged again?

Copy link
Author

@laur89 laur89 Apr 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which will be logged again?

It won't be logged again. The err is rethrown only for the sake of control flow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a binary situation, you can use return logic.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think we should continue this discussion under the return code chain

}

when (result) {
RootInstallerResult.FAILURE ->
RootInstallerResult.SUCCESS ->
logger.info("Mounted the APK file")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Mounting" is an installation method. I think we don't need more granularity than "install" for both cases. Mentioning that it was mounted is not necessary too for the reason that the CLI input already mentions --mount as an installation method.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'ite, both {RootInstallerResult.SUCCESS, AdbInstallerResult.Success} will log

Installed the APK file

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy w/

RootInstallerResult.FAILURE -> {
    logger.severe("Failed to mount the APK file")

or want it changed?

is AdbInstallerResult.Failure ->
logger.severe(result.exception.toString())
else ->
throw Exception()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

raising an empty exception doesn't look right to me.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as explained above - it's for control flow only.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, you can probably just return?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like above, we should continue this discussion under the return code chain

}
}

runBlocking {
deviceSerials?.map { async { install(it) } }?.awaitAll() ?: install()
try {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally find exceptions ugly/messy code. They introduce nesting and unnecessary blocks of code. Using return values seems simpler for "binary" cases. Exceptions have particular use case for raising messages or multiple kinds of cases not just true or false.

Copy link
Author

@laur89 laur89 Apr 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you pefer not to use exceptions for this control flow, then what do you propose?
Perhaps change InstallCommand/UninstallCommand to implement Callable instead of Runnable and return code (i.e. Int) from install() / uninstall()?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the expected way of returning an exit code for PicoCLI? If so, every subcommand should be subject to this change.

Copy link
Author

@laur89 laur89 Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly no idea what the common there pattern is.

}

when (result) {
RootInstallerResult.FAILURE ->
RootInstallerResult.SUCCESS ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am just noticing code duplication here and in the patch subcommand, possibly extracting into a common function makes sense.

@oSumAtrIX oSumAtrIX changed the title feat: improve install/uninstall error handling feat: Increase installation logging granularity and set process exit code properly Apr 20, 2025
@oSumAtrIX
Copy link
Member

If we introduce exit code, then it should probably be introduced for more scenarios like failing to patch, failing to connect to the device, failing to install or other types of failures consistently, in another PR.

@laur89 laur89 force-pushed the improve-install-uninstall-logging branch 2 times, most recently from a7de7a0 to 7ce78b7 Compare April 21, 2025 01:00
laur89 added 3 commits April 21, 2025 03:32
- handle {Root,Adb}InstallerResult in InstallCommand & UninstallCommand.
  this is a non-functional change, only aiming to improve the logged
  feedback to the user
- fixes ReVanced#362
- exit InstallCommand/UninstallCommand with exit code 1 on detected
  command failures or thrown exceptions; log where appropriate
- fixes ReVanced#362
@laur89 laur89 force-pushed the improve-install-uninstall-logging branch from 7ce78b7 to 830bd97 Compare April 21, 2025 01:32
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

Successfully merging this pull request may close these issues.

2 participants