Fix SAF/VFS path resolution crash by using checked IOException instead of unchecked NPE#1933
Open
cw2k wants to merge 2 commits intoMuntashirAkon:masterfrom
Open
Fix SAF/VFS path resolution crash by using checked IOException instead of unchecked NPE#1933cw2k wants to merge 2 commits intoMuntashirAkon:masterfrom
cw2k wants to merge 2 commits intoMuntashirAkon:masterfrom
Conversation
Add a new utility method `requireNonNullOrThrow(...)` to ExUtils.
This helper validates a nullable value and throws a caller‑provided
IOException when the value is null. It provides a safer and more explicit
alternative to `Objects.requireNonNull(...)`, which always throws a
NullPointerException and is therefore unsuitable for expected I/O error
conditions such as missing files or invalid VFS path components.
Usage example:
´´´´
import io.github.muntashirakon.AppManager.utils.ExUtils;
...
DocFile = ExUtils.requireNonNullOrThrow(
someObj.findFile(FileName),
() -> new IOException("Invalid File")
);
´´´´
This prepares the codebase for fixing VFS path resolution in PathImpl,
where null values must be treated as I/O errors rather than programming
errors.
Signed-off-by: cw2k <3834079+cw2k@users.noreply.github.com>
…-related failures Replaced unsafe Objects.requireNonNull(...) calls in SAF and VFS path resolution with ExUtils.requireNonNullOrThrow(...). DocumentFile.fromTreeUri(), fromSingleUri(), and findFile() may return null in normal file‑related failure cases. Previously this triggered an unchecked NullPointerException, crashing the app. These conditions are I/O failures, not programming errors, and should be reported via the checked IOException type. PathImpl now throws IOException for invalid URIs and missing VFS components, improving robustness and aligning error handling with the rest of the API. Signed-off-by: cw2k <3834079+cw2k@users.noreply.github.com>
Owner
|
Is this your own work? The description reads as if it was created using gen AI. We have strict policy of not accepting any AI generated contents. |
Contributor
Oh didn't even think to check, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reviewer Summary
On some file errors (e.g. invalid file name or invalid SAF/VFS path),
PathImpl now throws a checked IOException that is handled by the caller.
Previously these situations produced an unchecked NullPointerException,
which bypasses normal error handling and ultimately crashes the app.
This change fixes #1932 and aligns file‑related failures with the
expected checked‑exception model.
description
This PR fixes the crash described in issue #1932.
PathImpl previously relied on Objects.requireNonNull(...) in several
SAF and VFS resolution paths. When DocumentFile.fromTreeUri(),
fromSingleUri(), or findFile() returned null (e.g. invalid SAF URI,
missing permissions, or non-existing VFS path components), the code
threw an unchecked NullPointerException ( in short NPE ) , causing the app to crash.
These cases represent normal file-related failure conditions and should
be reported via a checked IOException rather than an unchecked NPE.
Changes included:
validation with caller-defined IOException.
crashing the app.
This aligns PathImpl with the expected error-handling model, improves
robustness, and prevents crashes when users enter invalid paths.