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

Refactor unreachable default case in JsonReader#peek #2809

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

aldenbro
Copy link

Purpose

Refactored unreachable default case in JsonReader#peek so that it can be reached while keeping existing functionality.

Checklist

  • New code follows the Google Java Style Guide
    This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.
    Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
  • If necessary, new public API validates arguments, for example rejects null
  • New public API has Javadoc
    • Javadoc uses @since $next-version$
      ($next-version$ is a special placeholder which is automatically replaced during release)
  • If necessary, new unit tests have been added
    • Assertions in unit tests use Truth, see existing tests
    • No JUnit 3 features are used (such as extending class TestCase)
    • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
  • mvn clean verify javadoc:jar passes without errors

aldenbro and others added 3 commits February 20, 2025 15:52
Refactored unreachable default case in `JsonReader#peek` so that it can be reached while keeping existing functionality.
Refactore unreachable default case in `JsonReader#peek`
@aldenbro aldenbro changed the title Refactore unreachable default case in JsonReader#peek Refactor unreachable default case in JsonReader#peek Feb 20, 2025
@eamonnmcmanus
Copy link
Member

Can you say something about the rationale for this change? I'm particularly concerned about control flow depending on whether or not assertions are enabled.

@aldenbro
Copy link
Author

The reason for making this change is to increase code coverage.

As p is effectively operating as an enum, no invalid values should ever be present, and thus the assertion should never fail.

@eamonnmcmanus
Copy link
Member

I see. Though it's a bigger change, I think I would prefer to see the use of a genuine enum here. I'm pretty sure the use of ints is because enums used to be frowned on with Android. But that's no longer the case. If we had an enum then we could have a known-exhaustive switch here and put throw new AssertionError() after it. I hope your code-coverage tool is smart enough to determine that that assertion isn't reachable.

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.

3 participants