[YANGIDE-15] Sometimes get NPE in HelpCompositionUtils.getNodeHelp(ASTNode) Created: 16/May/16 Updated: 03/Jun/16 Resolved: 03/Jun/16 |
|
| Status: | Resolved |
| Project: | yangide |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | David M. Karr | Assignee: | Dhevendran Kulandaivel |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 5891 |
| Description |
|
I sometimes see the following stacktrace: Exception:java.lang.NullPointerException: null Besides the error dialog, I don't see any consequences from it. Here's the "getNodeHelp" method: String info = getIndexedInfo(node); From the context of line 50, it appears that "node" is null. I don't think I've ever seen this happen when I had the debugger connected and a breakpoint enabled here. I've tried to connect up the debugger after I see this happen, but I've never been able to repeat it when the debugger is connected. A simple fix could be to just return null if node is null. It appears from inspecting the "TextViewerHoverManager" code that calls this indirectly, that it would deal smoothly with a null return value. However, it's not clear whether getting a null value here is an indication of something else going wrong. |
| Comments |
| Comment by Dhevendran Kulandaivel [ 02/Jun/16 ] |
|
Hi David M. Karr The fix is available in https://git.opendaylight.org/gerrit/#/c/39743/ Thanks & Regards, |
| Comment by David M. Karr [ 02/Jun/16 ] |
|
Were you able to figure out how to repeat this reliably? I would have fixed this myself, but I wanted to understand why this was happening, or at least be able to repeat it. |
| Comment by Dhevendran Kulandaivel [ 02/Jun/16 ] |
|
(In reply to David M. Karr from comment #2) Hi David M. Karr Thanks for your comment. |
| Comment by David M. Karr [ 02/Jun/16 ] |
|
The change for this has been merged. I suppose we can mark it resolved, but it's a little annoying to mark a bug resolved that I don't even know how to test for. |
| Comment by Dhevendran Kulandaivel [ 03/Jun/16 ] |
|
Hi David M. Karr This can be marked it as resolved since we are pretty sure ( in the implementation angel) that the exception is due to lack of null check at line number 50 in old code (i.e. 52 in merged code) Let us see whether this occurs in any of the product testing since we do not have any definite reproducer Thanks & Regards, |