本文主要是介绍NullPointerException 处理规范 --- 记一次空指针引起的小组风波，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
All input is evil。
一切的入参都是邪恶的，作为编码人员都无法掌握。如果不针对这些参数做校验，我们的程序就会出现这样或那样的问题。NullPointerException作为一个老生常谈的话题，我这里又把它拎出来了。
本次讨论这个话题源于司内一个案例的NullPointerException的复盘。下面我贴一下相关代码。因为涉及到公司的业务源码，会有一定的隐饰。
/*** 出现NullPointerException位置已经标出，大家自行阅读* InnerException 是一个自定义异常* @param ids* @return* @throws InnerException*/public Map<String, List<User>> getAdCards(List<String> ids) throws InnerException {List<Long> userIds = decodeLiveIds(ids);List<User> Users = liveBiz.getUsers(getUserIdOrNull(), userIds);return users;}private List<Long> decodeLiveIds(List<String> userIds) throws InnerException {List<Long> ids = new ArrayList<>();for (String userId : userIds) { //此处出现NullPointerExceptionids.add(UserUtil.decode(userId));}return ids;}其实一开始我是这样想的，我觉得“所有的公共方法一定要可接受所有可能的参数。因为我们不知道调用公共方法的developer对公共方法的入参全部情景考虑周全，并对入参做全场景校验”
但是我的同事一开始是这样想的“单个方法只做一件事，符合单一职责原则。把校验规则放到上层，本抽取方法只做解密操作”
由此看来，我们针对此问题有一个共同点 - “此处参数要做校验”
我们不同的观点是 - “做校验的位置”
针对这种情况，大家一般是怎么处理的呢？大家可以自行考虑下再向下阅读。
经过复盘总结，结合业内规范和笔者公司的规范，最终给出如下建议供大家遵循：
-
对外提供的开放接口，不管是RPC/API/HTTP接口，必须做参数校验；
-
极有可能被循环调用的方法，但在方法说明里必须注明外部参数检查，不需要做方法校验；
-
被声明为private只会被自己代码所调用的方法。如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。
针对笔者给到的建议，大家可在评论区留言自己的观点，大家一起探讨！
附：
复盘后，司内是在调用方做的参数校验，并在被调用方的方法描述中添加可用入参描述！
这篇关于NullPointerException 处理规范 --- 记一次空指针引起的小组风波的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
