为人父母, 一个比较纠结的事情, 就是到底怎么保护那个啥也不懂的小家伙. 若是护着她太紧了, 会不会让她失去和外部接触, 学习的机会, 变得孤僻, 依赖性强? 若是保护不利, 被人欺负了, 或者甚至被拐跑了, 后悔药没地方买呀. 到底要不要告诉她外面有不少坏人呐?
唉. 不自寻烦恼了. 埋头写代码!
不过, 嗯, 这个好像我写代码怎么也在想着相似的东西? "要不要检查这个参数是否是null?", "要不要判断当前状态对不对?"
一个好编程习惯是尽可能不要用null, 除非特殊状况, 参数都不容许是null. 而那些特殊的须要null的场合, 用
@Nullable标注出来.
通常状况下, 若是你立刻就会调用girl.kiss(), 这个girl若是是null的话, 你立刻就能即时获得一个NullPointerException, jvm已经帮你作了null检查. 可是有时候, 好比对构造函数来讲, 参数不是立刻使用, 而是存在成员变量里面, 之后再用. 这时候检查就很重要了. 不然, 若是客户不当心传递一个null, 错误就要延后到可能好久之后才会发现了.
最直观的检查就是:
if (girl == null) {
throw new NullPointerException("谁这么缺德, 给我一个山寨美眉呀?!");
}
可是这有点繁琐, 瓜娃有一个工具, 叫
Preconditions.
用它, 上面的代码能够简化成:
Preconditions.checkNotNull(girl, "谁这么缺德, 给我一个山寨美眉呀?!");
Preconditions还有两个经常使用的检查: checkArgument()和checkState(). 用法大同小异. 一个用来检查参数, 一个用来检查对象状态. 一个抛IllegalArgumentException, 一个抛IllegalStateException. Preconditions这些工具函数有一个潜在的问题: 当你写测试同时用测试覆盖工具的时候, 若是你用传统的if-else, 测试覆盖工具会告诉你若是你忘记了测试那个错误状况. 而用了Preconditions, 这些工具就被骗了, 只会傻乎乎地报告100%覆盖.