JSONObject类中getIntValue getLongValue等方法的设计建议

gtd 发布于 2012/12/12 16:05

阅读 10K+

fastjson

public Integer getInteger(String key) {
        Object value = get(key);

        return castToInt(value);
    }

    public int getIntValue(String key) {
        Object value = get(key);

        if (value == null) {
            return 0;
        }

        return castToInt(value).intValue();
    }

上面是 JSONObject类中的得到in和Integer值的方法

下面是TypeUtils中的 castToInt 方法

public static final Integer castToInt(Object value) {
        if (value == null) {
            return null;
        }

        if (value instanceof Integer) {
            return (Integer) value;
        }

        if (value instanceof Number) {
            return ((Number) value).intValue();
        }

        if (value instanceof String) {
            String strVal = (String) value;
            if (strVal.length() == 0) {
                return null;
            }

            return Integer.parseInt(strVal);
        }

        throw new JSONException("can not cast to int, value : " + value);
    }

很显然，如果值是一个不能转成int的非法串（例如空串）时，调用 JSONObject的getIntValue()方法会抛出空指针异常。（在使用中感觉不太方便）

既然 value==null的时候会返回默认值 0，在转换错误的时候也直接返回默认值0 感觉会更统一和方便。

或者提供一个类似如下实现有默认值的版本

public int getIntValue(String key, int defaultValue) {
		Object value = get(key);

		if (value == null) {
			return defaultValue;
		}
		try {
			return castToInt(value).intValue();		
		} catch(Exception e) {
			return defaultValue;
		}
     
    }

我的建议是

getInteger 返回包装类型的方法不抛异常，不能转成Integer直接返回null

getIntValue 返回原始数值类型的方法更也不用抛异常，返回默认值

其他 getLong 等方法也一样。

如果已有接口不方便修改，是否可以增加 getIntegerSilently getIntValueSilently 等不抛出异常的安静方法？谢谢。

@wenshao

加载中

wenshao

2012/12/12 16:08

谢谢你的建议，分析得很仔细，不错!

但是我的看法和你有所不同，我觉得如果不抛错返回默认值，这个会导致业务代码的错误很难被发现。

评论 (1) 引用此答案举报

冰封情

2016/12/01 20:44

你的这个业务更严谨也对，但是有时候的确需要给默认值的，作为开源的第三方多写几个方法也没几行嘛，如果jar提供了就方便多了，这样不是更好吗？如果要求的严谨的，就用严谨方法，如果求方便的就用给defval的方法？希望开源的作者考虑下！

回复举报

段

段易村

2012/12/12 16:21

代码还可以，不错

评论 (0) 引用此答案举报

gtd

2012/12/12 16:23

引用来自“wenshao”的答案

谢谢你的建议，分析得很仔细，不错!

但是我的看法和你有所不同，我觉得如果不抛错返回默认值，这个会导致业务代码的错误很难被发现。

我的理解是, 业务中调用 getIntValue()等返回原始数值类型的方法 , 绝大部分会在有数据转换异常的情况使用默认值。参考 @红薯的 RequestContext 源码中 http://www.oschina.net/code/snippet_12_2

public long param(String name, long def_value) {
		return NumberUtils.toLong(param(name), def_value);
	}

	public int param(String name, int def_value) {
		return NumberUtils.toInt(param(name), def_value);
	}

	public byte param(String name, byte def_value) {
		return (byte)NumberUtils.toInt(param(name), def_value);
	}

apache的NumberUtils中的toInt方法

public static int toInt(String str, int defaultValue) {
        if(str == null) {
            return defaultValue;
        }
        try {
            return Integer.parseInt(str);
        } catch (NumberFormatException nfe) {
            return defaultValue;
        }
    }

就是这样处理。

其实抛出异常、返回默认值都没有问题，抛异常严谨，但返回默认值使用更顺手更爽，oschina 的 param方法使用中就是这样。

所以，不修改现有方法，不知道能否考虑增加不抛异常的安静版本？

评论 (0) 引用此答案举报