Summary: | Failure in model test 20050921-1200 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> | ||||||||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||||
Severity: | normal | ||||||||||||
Priority: | P3 | CC: | philippe_mulet | ||||||||||
Version: | 3.2 | ||||||||||||
Target Milestone: | 3.2 M3 | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows XP | ||||||||||||
Whiteboard: | |||||||||||||
Attachments: |
|
Description
Olivier Thomann
2005-09-21 19:12:05 EDT
Created attachment 27369 [details]
Proposed fix
With this patch, no NPE will be thrown anymore.
Seems a bit of a hack to allow convert null values. Why is someone setting a null table in there ? Is this platform dependant ? Normal senders should at least pass an empty table (Scanner.EMPTY_LINE_ENDS) I think there must be a path in the code where the parsed unit doesn't retrieve the lineEnds from scanner before reaching this point. This would be possible if the scanner didn't record the line ends. We might want to add an empty array when the line ends are persisted. What is suspicious is the fact that this test suddendly failed without any changes from our side. Also the patch is not a hack. The NPE is not specified and doesn't add anything. Created attachment 27404 [details]
Proposed fix
Created attachment 27613 [details]
New patch
This patch ensures that null is never passed to the setLineEndTable(). If null is about to be passed, we convert it to an empty array. Created attachment 27615 [details]
New patch
I moved the logic on the compilation result class.
Fixed and released in HEAD. Tests should not fail anymore with NPE. Verified for 3.2 M3 using build I20051025-0800+v_619 |