Summary: | Invalid "Potential null pointer access" warning message | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Mohsen Saboorian <mohsens> |
Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> |
Status: | VERIFIED INVALID | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | Olivier_Thomann, srikanth_sankaran, stephan.herrmann |
Version: | 3.6.1 | ||
Target Milestone: | 3.7 M5 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Whiteboard: |
Description
Mohsen Saboorian
2011-01-05 07:06:32 EST
The check (param1 == null) tells the compiler that the developer expects both null and non-null values. So any dereference of param1 after this check is flagged as a potential null dereference. If the check is only for robustness and null is actually not expected here, then perhaps an assert is a better way to reflect your intention. Once bug 186342 is released you may even avoid the check altogether by declaring the parameter as "@NonNull String param1". How about this: int b = param1 == null ? 1 : 2; if (StringUtils.isNotBlank(param1) { param1.trim(); } I still receive that warning even when I used a method which checks for nullity. I believe this is raised because JDT is not inspecting methods recursively. (and this is quite reasonable) Is this the right behavior based on Java compiler spec, or is a JDT-specific warning? Thanks, Mohsen (In reply to comment #2) > How about this: > int b = param1 == null ? 1 : 2; > > if (StringUtils.isNotBlank(param1) { > param1.trim(); > } > > I still receive that warning even when I used a method which checks for > nullity. I believe this is raised because JDT is not inspecting methods > recursively. (and this is quite reasonable) Is this the right behavior based on > Java compiler spec, or is a JDT-specific warning? > > Thanks, > Mohsen This is purely a JDT-specific warning. We currently dont do inter-procedural analysis, so passing a variable as a parameter to a method call makes no difference in our analysis. As Stephan already pointed out,fix for bug 186342 will make it convenient to specify null status of variables using annotations. I intend to close this as INVALID. > This is purely a JDT-specific warning. We currently dont do inter-procedural
> analysis, so passing a variable as a parameter to a method call makes no
> difference in our analysis. As Stephan already pointed out,fix for bug 186342
> will make it convenient to specify null status of variables using annotations.
>
> I intend to close this as INVALID.
Thanks for your explanation. Feel free to mark it INVALID.
. Verified for 3.7 M5 |