Bug 128962 - [compiler][null] incorrect analysis within try finally with a constructor
Summary: [compiler][null] incorrect analysis within try finally with a constructor
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 128963 129117 136509 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-02-22 07:07 EST by Danny Yates CLA
Modified: 2006-04-14 05:52 EDT (History)
2 users (show)

See Also:

Attachments
HEAD - suggested fix plus test case (5.70 KB, patch)
2006-03-23 07:12 EST, Maxime Daniel CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Danny Yates CLA 2006-02-22 07:07:38 EST 
With the following method:

  public CachedRowSet executeQuery(Connection conn, String sqlStatement)
  throws  SQLException {
    CachedRowSet result = null;
    Statement st = conn.createStatement();
    try {
      result = new CachedRowSetImpl();
      ResultSet resultSet = st.executeQuery(sqlStatement);
      try {
        result.populate(resultSet);
      } finally {
        resultSet.close();
        resultSet = null;
      }
    } finally {
      st.close();
      st = null;
    }
    return result;
  }

the variable st in the line with executeQuery() is highlighted with the warning: "The variable st can only be null; it was either set to null or checked for null when last used".

Clearly, this is not the case. I guess this is something to do with the finally block. Strange then, that the resultSet variable is not affected.

If I delete the "st = null" line, the warning goes away, but the resultSet variable is still not highlighted.
Comment 1 Olivier Thomann CLA 2006-02-22 08:07:06 EST 
*** Bug 128963 has been marked as a duplicate of this bug. ***
Comment 2 Maxime Daniel CLA 2006-02-22 08:27:59 EST 
Reproduced with I20060217-1115 (aka M5).
Comment 3 Maxime Daniel CLA 2006-03-22 11:37:36 EST 
Reduced the test case to:

public class X {
  public void foo(Y y) throws  E {
    try {
      new Y();
      y.bar(); // should be quiet
    } finally {
      y = null;
    }
  }
}
class Y {
	Y() throws E {
	}
	void bar() throws E {
	}
}
class E extends Exception {
	private static final long serialVersionUID = 1L;
}

(NullRefenceTest #519.)
Comment 4 Maxime Daniel CLA 2006-03-23 07:12:16 EST 
Created attachment 36803 [details]
HEAD - suggested fix plus test case
Comment 5 Maxime Daniel CLA 2006-03-23 07:15:06 EST 
Added NullReferenceTest #520 to track the same issue into QualifiedAllocationExpression.

The problem comes from a side effect on flow info null bits when stored along with exceptions within the enclosing context.
Comment 6 Maxime Daniel CLA 2006-03-23 08:29:24 EST 
*** Bug 129117 has been marked as a duplicate of this bug. ***
Comment 7 Maxime Daniel CLA 2006-03-23 10:06:56 EST 
Fixed and released in HEAD.
Verification can leverage the original submission or the added test cases. The
key is the fact that the constructor may throw a checked exception.
Comment 8 David Audel CLA 2006-04-13 11:20:15 EDT 
The Target Milestone must be 3.2M6 and not 3.2RC1. I correct it.

Verified for 3.2 M6 using build 3.2M6
Comment 9 Maxime Daniel CLA 2006-04-14 05:52:01 EDT 
*** Bug 136509 has been marked as a duplicate of this bug. ***