Bug 150082 - [compiler][null] Null reference warning ignores try blocks?
Summary: [compiler][null] Null reference warning ignores try blocks?
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.3 M3   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 151083 159401 (view as bug list)
Depends on:
Blocks: 157154
  Show dependency tree
 
Reported: 2006-07-08 18:57 EDT by Jens Elkner CLA
Modified: 2006-10-30 14:07 EST (History)
4 users (show)

See Also:

Attachments
Fix + test cases for this bug + bug 158000 (8.38 KB, patch)
2006-09-25 07:35 EDT, 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 Jens Elkner CLA 2006-07-08 18:57:25 EDT 
When I enable 'Null reference: Warning' in Java|Compiler|Errors/Warnings it seems, that the content of a try block is ignored and thus leads to wrong warnings.

E.g.:

	private String bla(StreamSource src) {
		String vers = null;
		XMLStreamReader in = null;
		try {
			in = Stax.getReader(src, "details");
			if (in == null) {
				return null;
			}
			vers = in.getAttributeValue(null, "version");
			while (in.hasNext()) {
				in.next();
			}
		} catch (XMLStreamException e) {
			log.warn(in.getLocation() + ": " + e.getLocalizedMessage());
			vers = null;
		} finally {
			if (in != null) {
				try { in.close(); } catch (Exception e) { /**/ }
			}
			try { src.getInputStream().close(); } catch (Exception e) { /**/ }
		}
		return vers;
	}

The IDE issues a false warning for in and vers references in the catch block ...
Comment 1 Maxime Daniel CLA 2006-07-10 03:22:57 EDT 
Assuming that getReader (and no other method used into the try block) bears a 'throws XMLStreamException' clause, then the only way to get into the catch block is to fail into getReader, and to bypass the assignment to in (and vers). Hence the beginning of the catch block sees vers and in as they are at the top of the method, that is null.
This is only an example of what could explain the described behavior.
There may still be a bug though. Please reopen with further information (which methods throw what) if you believe so.
Comment 2 Jens Elkner CLA 2006-07-10 04:05:03 EDT 
Sorry, forgot to mention it :(:
Stax.getReader does not throw any checked exception. Only the in.next() in the while block may throw an XMLStreamException ...
Comment 3 Maxime Daniel CLA 2006-07-11 03:41:57 EDT 
Reproduced, thanks.
Comment 4 Maxime Daniel CLA 2006-09-20 09:49:17 EDT 
The problem pertains to unchecked exceptions. Unchecked exceptions are reachable from any point in the try block, just like finally is. Accordingly, we must mitigate the null info made available to the catch block, leveraging the current flow context initsOnFinally member.
Adding test cases NullReferenceTest 525->527.
Will post a patch when releasing (in order to avoid posting a cumulative patch).
Waiting for 3.3 M2 to be declared.
Comment 5 Maxime Daniel CLA 2006-09-25 07:35:35 EDT 
Created attachment 50812 [details]
Fix + test cases for this bug + bug 158000

The fix essentially mitigates unchecked exceptions flow info with the initsOnFinally value so as to take into account all possible exit points. Re. 158000, erroneous return statements have been replaced by continue statements as needed.
Comment 6 Maxime Daniel CLA 2006-09-25 07:36:22 EDT 
Realeased for 3.3M3.
Comment 7 Maxime Daniel CLA 2006-09-26 02:17:34 EDT 
*** Bug 151083 has been marked as a duplicate of this bug. ***
Comment 8 Maxime Daniel CLA 2006-10-05 07:47:02 EDT 
*** Bug 159401 has been marked as a duplicate of this bug. ***
Comment 9 Frederic Fusier CLA 2006-10-29 07:49:11 EST 
Comment 6 should read "Released for 3.3M3." instead.
Comment 10 Olivier Thomann CLA 2006-10-30 14:07:31 EST 
Verified for 3.3 M3 using warm-up build I20061030-0010