说明：无法通过预检查的异常除外，比如，在解析字符串形式的数字时，可能存在数字格式错误，不得不通过 catch NumberFormatException 来实现。
正例：if (obj ≠ null) {…}
反例：try { obj.method(); } catch (NullPointerException e) {…}
对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。
说明：对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，这是一种不负责任的表现。
正例：用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入密码过于简单，在程序上作出分门别类的判断，并提示给用户。
说明：通过反射机制来调用方法，如果找不到方法，抛出 NoSuchMethodException。
什么情况会抛出NoSuchMethodError 呢？
二方包在类冲突时，仲裁机制可能导致引入非预期的版本使类的方法签名不匹配，
或者在字节码修改框架（比如：ASM）动态创建或修改类时，修改了相应的方法签名。
这些情况，即使代码编译期是正确的，但在代码运行期时，会抛出 NoSuchMethodError。
不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回 null 值。
说明：本手册明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败、序列化失败、运行时异常等场景返回 null 的情况。
反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。
数据库的查询结果可能为 null。
集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。
远程调用返回对象时，一律要求进行空指针判断，防止 NPE。
对于 Session 中获取的数据，建议进行 NPE 检查，避免空指针。
级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。
正例：使用 JDK8 的 Optional 类来防止 NPE 问题
而应用内部推荐异常抛出；
跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess()方法、errorCode、errorMessage；而应用内部直接抛出异常即可。
说明：关于 RPC 方法返回方式使用 Result 方式的理由：
1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。
2）如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。
