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

AutoFactory checkNotNull index in error message is 1-indexed, despite java being 0-indexed #1495

Closed
mhansen opened this issue Apr 28, 2023 · 5 comments
Assignees

Comments

@mhansen
Copy link

mhansen commented Apr 28, 2023

AutoFactory gives an error message

@AutoFactory method argument is null but is not marked @Nullable. Argument index 1

I wasn't sure if this meant the first or second element, as java is 0-indexed. IndexOutOfBoundsException is 0-indexed. But in AutoFactory this turns out to be 1-indexed.

It's a bit confusing.

The problem starts here where we start the loop at 1:

for (int argumentIndex = 1; parameters.hasNext(); argumentIndex++) {
:

      for (int argumentIndex = 1; parameters.hasNext(); argumentIndex++) {

Options:

  1. Change to 0-indexed? Optionally, also make clear that it's 0-indexed.
  2. Make clear in the error message you mean it's 1-indexed?
  3. Put the argument name (text) in the error message? It's what AutoValue does, I think. Neatly sidesteps this issue and does not require users to count.

Thoughts?

@eamonnmcmanus
Copy link
Member

I went back and looked at the change that introduced these index numbers, and found this from @ronshapiro in the review comments: "I didn't include the actual parameter name for Proguard obfuscation reasons." (cl/126078797 for those who have access.) I wonder if we could do something similar to AutoValue, which has a -A option you can use if you don't want identifiers in the generated code. We'd have to reverse the polarity here, though, since presumably there is lots of Android code that would suddenly get much bigger. Or it could be a new boolean element inside @AutoFactory.

At Google we have @AutoFactory methods with 80 parameters, so telling you that parameter 43 was null isn't all that helpful.

Anyway I think we could at least add text like "first argument is 1" to the message.

@eamonnmcmanus
Copy link
Member

Probably just saying "Argument number 1" rather than "Argument index 1" would be enough for the rewording? We often index from 0, but we don't usually number things from 0.

[I'm trying not to be bothered by the wording of the rest of the message. The argument is null, but it's the parameter that is @Nullable.]

@mhansen
Copy link
Author

mhansen commented Apr 29, 2023 via email

@ronshapiro
Copy link
Contributor

I think "number 1" is also probably a source of confusion, though possibly less. I vote for adding the start index/number is best. Or something like argument 1 of 7

@mhansen
Copy link
Author

mhansen commented Apr 30, 2023 via email

copybara-service bot pushed a commit that referenced this issue May 3, 2023
"Argument index 1" could plausibly mean the second argument, but "Argument 1 of 3" is more obviously the first. It also makes it easier to count backwards from the end if there are a lot of arguments.

Fixes #1495.

RELNOTES=The exception message for a null value now indicates not only which number argument it is but also how many arguments there are in total. This may lead to a small increase in code size.
PiperOrigin-RevId: 528020559
copybara-service bot pushed a commit that referenced this issue May 3, 2023
"Argument index 1" could plausibly mean the second argument, but "Argument 1 of 3" is more obviously the first. It also makes it easier to count backwards from the end if there are a lot of arguments.

Fixes #1495.

RELNOTES=The exception message for a null value now indicates not only which number argument it is but also how many arguments there are in total. This may lead to a small increase in code size.
PiperOrigin-RevId: 528020559
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants