Some logic clarifications in com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter#doConvertToNumber(Map,Object,Class)

[Jason Pyeron <jp...@pdinc.us>]

Looking over the beginning snipet

            if (toType == BigDecimal.class) {
                return new BigDecimal((String) value);
            } else if (toType == BigInteger.class) {
                return new BigInteger((String) value);
            } else if (toType.isPrimitive()) {
                Object convertedValue = super.convertValue(context, value,
toType);
                String stringValue = (String) value;
                if (!isInRange((Number)convertedValue, stringValue,  toType))
                        throw new XWorkException("Overflow or underflow casting:
\"" + stringValue + "\" into class " + convertedValue.getClass().getName());

                return convertedValue;
            } else {
                String stringValue = (String) value;
                if (!toType.isPrimitive() && (stringValue == null ||
stringValue.length() == 0)) {
                    return null;
                }
		...
		}

I am trying to figure out why the value instanceof checks are before the isNull
/ isEmpty checks.

Moving it around fixes the "" to BigDecimal issues, and I cannot find a side
effect. Could existing uses be relying on the exceptions being thrown when doing
a new BigDecimal("")?

-Jason



--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Some logic clarifications in com.opensymphony.xwork2.conversion.impl.XWorkBasicConverter#doConvertToNumber(Map,Object,Class)

[Maurizio Cucchiara <mc...@apache.org>]

>
> Could existing uses be relying on the exceptions being thrown when doing
> a new BigDecimal("")?


There is no doubt that changing the order of instanceof/nullity check the
outcome is different.
As you yourself pointed out new BigDecimal("") throws a
NumberFormatException.
AFAIU the toType takes the precedence over the value itself.
Sounds like: if you want a BigDecimal and you provide a wrong value, you
will get an exception.

I could be wrong as I took a very quick look at the source code.
Did you check if there is a test which illustrates the expected behavior?


Twitter     :http://www.twitter.com/m_cucchiara
G+          :https://plus.google.com/107903711540963855921
Linkedin    :http://www.linkedin.com/in/mauriziocucchiara

Maurizio Cucchiara