Community
Participate
Working Groups
Build Identifier: 20090920-1017 In a recent project i discovered, that calling the method "getUpper()" on a Property-object, always returns 1. Reproducible: Always Steps to Reproduce: 1. Create a Property instance, for which property.upperValue.value = 10 (only an example here, it does also not work with other values) 2. call getUpper() 3. look at the value you got returned: It will be 1
I have tracked down the issue via debugging the calls: MultiplicityElementImpl.getUpper() -> MultiplicityElementOperations.getUpper(this) -> MultiplicityElementImpl.upperBound() -> MultiplicityElementOperations.upperBound() -> ValueSpecificationImpl.unlimitedValue() -> ValueSpecificationOperations.unlimitedValue(this) The problem is an unconditionally thrown "UnsupportedOperationException" by ValueSpecificationOperations.unlimitedValue(). This exception gets catched by MultiplicityElementOperations.upperBound(). But instead of doing any exception handling here, the body of the catch statement is: "catch (UnsupportedOperationException uoe) { // do nothing }" This results in the method "MultiplicityElementOperations.upperBound()" returning 1, as this seems to be the default case, when no multiplicity has been specified. A possible workaround for those, who need the functionality of querying the upper multiplicity of a MultiplicityElement, would be to use the method "getUpperValue()" instead and call "interValue()" on this ValueSpecification.
(In reply to comment #1) > A possible workaround for those, who need the functionality of querying the > upper multiplicity of a MultiplicityElement, would be to use the method > "getUpperValue()" instead and call "interValue()" on this ValueSpecification. I meant "getUpperValue().integerValue()"
Since primitive types in Java must have a value, it's not possible for lower and upper (as opposed to lowerValue and upperValue) to not have a value. Currently, the default multiplicity is returned in cases where these should have been "undefined"; in hindsight, a better approach may have been to define a constant (e.g., -2) to indicated "undefined", but changing this at this point could have undesirable compatibility effects for clients. Given that the workaround of inspecting the upperValue (or lowerValue) exists, I'm marking this issue as "won't fix".
