CDV ❯ TCObjectPhysical.literalValueChanged() methods call setPeerObject() with null, which will throw NPE
-
Bug
-
Status: Resolved
-
2 Major
-
Resolution: Won't Fix
-
DSO:L1
-
-
interfaces
-
Reporter: amiller
-
November 13, 2008
-
0
-
Watchers: 2
-
February 12, 2014
-
February 12, 2014
Description
We found this with FindBugs. TCObjectPhysical.literalValueChanged() and .setLiteralValue() both explicitly call TCObjectImpl.setPeerObject() with a null value (in the case of receiving a null value). setPeerObject() dereferences the pased value, so is guaranteed to throw an NPE in this case. Either setPeerObject() should be expecting a null OR the TCObjectPhysical methods should be doing something different OR they shouldn’t ever get null either.
Comments
Saravanan Subbiah 2008-11-13
Fiona OShea 2008-11-14
Whenever you want to do this?
Alex Miller 2008-11-14
The expectation of nulls down this code path may be affected by this other jira - if literal roots are reassignable (to null), then I think it can happen.
Alex Miller 2008-11-14
At current code status, I think that it’s not possible to receive nulls down this path, so this potential NPE will never actually occur. I’m going to defer making this an assertion however until someone decides CDV-948 and determines whether tc literal non-primitives and/or non-literal roots can be mutated (presumably including mutated to null).
Hung Huynh 2014-02-12
DSO is discontinued
I think we always pass ObjectID.NULL_ID and never null as such to literalValueChanged(). Anycase we should either change literalValueChanged() and setLiteralValue() to not send null or setPeerObject() to handle null.