nowto

错误要早发现早暴露，能在编译器暴露的，就不要等到运行期。就算运行期也要能早暴露尽早暴露。所以一般会在 public 函数开始处做参数校验，抛出业务相关异常；而且应该尽量在 javadoc 注明某参数不接受 null，会抛什么样的异常。

如果不做显式校验，而是使用到这个参数时依靠 jvm 自动报错：
1 、会晚； 2 、是一个业务无关的异常； 3 、随着重构的进行，入参和参数使用的位置可能会很远，甚至不在同一个方法

把他们叫在一起，你重构他们看着，这样他们才有长进

公司招人吗？

我跟楼主一样。。
在编程上边我自认我不算笨，但应该就是面试能力不行，没有机会进大公司。
我在想如果我当初一毕业就进了大厂，有了大厂的历练，现在应该挺牛逼的。

可能是他想强调这个方法有可能返回 null

我只是从 A 和 B 两个人来说，哪个应该担责更多，不同意应该让员工赔偿损失。
一个团队，出现问题不会只是一个人的责任，我同意“不管什么错，leader 都应该有责任”。

[要看 A 写的方法有没有完善的文档（比如 javadoc ）注释]
应该按照文档约定调用方法；文档上应该说明不合理调用产生的风险。

1. 如果 B 完全按照文档说明调用方法，发生了意料之外的 bug，那么应该 A 背锅。
2. 如果 B 没有按照 A 的文档说明调用了方法（比如没有仔细阅读文档，便调用了方法），或者干脆就没有文档，B 背锅。
这时，B 应该找 A，让其首先完善文档。

最好的做法，A 的方法应该做防御性编程，检测不合理调用并抛出合适异常，同时文档上也应该做说明。

坚果手机（锤子），肯定是全功能 Type-c，支持 TNT 桌面模式

不是连续续费，中间断了，还会有折扣优惠嘛？