String lookup(List<String> tree, String str){
for (String s : tree){
if (s == str){
return s;
} ;
}
return null
}
这里 tree 如果为 null， 这里将抛出异常，我们应该是在这里检查参数是否为空，如果为null 就返回，还是等待还是调用时抛出异常。
如果每个方法都检查入参是否为 Null 是否合适？
注:
实际工程总不仅仅是null, 当然null 是几乎所有暴露给外面的函数都应该考虑的,实际工程中还包括很多参数校验的例子. 如 你接受一个 ip 地址, 你是否需要检查 ip 地址是否合法.
一个参数从上到下传入, 经历多层调用, 每层都检查, 给人一种冗余的感觉, 不是一种非常优雅的做法. 所以,我想问, 作为一个稳定的工业级产品, 如果对参数处理, 自己没有一个非常满意的办法.
这个问题很好，我一般都检查的，持续关注这个问题
我一般这么做：
public / internal / protected 函数，检查所有可能为null的参数。因为调用者来源未知。
private 函数，调用者都是自己控制的，一般null到不了这一层。
java 方法入参是否总是需要检查?
答案是"否"。
关键在于tree的来源，导致客户端代码不得不写额外的代码处理null。
返回类型为数组或者集合的方法有没有理由返回null?
- 语义，是否一定要用null保证语义，很少有这种情况。
- 用null代替空数组可以避免分配数组的开销，但这几乎不是导致性能问题的源头。
- 声明一个不可变的零长度数组，我们每次都可以返回同一个零长度数组。
无论如何，返回类型为数组或者集合的方法没有理由返回null。
重要不是是否应该检查参数，而是这个函数的语义你想怎么定义。考虑这个问题，可以从precondition的角度和防御性编程的角度考虑。
以你的例子为例，List tree如果为null是否合理，str是否可能为null。对于为null的tree，你是否能返回一个合理的返回值，还是抛出一个异常。
如果你编写的是库一类的函数，即使是在项目中共享的库，最好都应该严格检查参数的precondition。如果是私有的函数，则可以假设caller会传入属于正确范围的参数值，适当的减轻函数的负荷。
类似情况在一些基本库中会出现。库对于不同输入产生什么样的输出会有不同的处理方法，不过对于输入值的范围都是有明确地规定的。设想，一段代码如果对于输入值的范围都不能确定，这个代码所对应的函数抽象f(x)的定义就是不明确的，必然有bug。
每个方法都检查是相当丑陋的行为，最好的方式就是由下到上均不要返回null，用空集合等代替，可以避免NPE。
如果你用jdk8可以参考下Optional机制，如果是低版本也可以看下Guava的Optional。
这个是JAVA语言遗留的问题，没有做强制的检查。
建议是'尽量'对输入参数进行检查，写肯定比不写要好，可以避免一些参数异常导致的问题。
但是实际操作一般是对有可能出错的参数进行必要的检查，否则大段检查参数的代码也会影响代码可读性，降低代码编写速度。
高级语言很多对此都会有比较友好的控制，例如强制校验、检查的语法糖。