关于异常的合理处理方式

 最近公司内要搞一个平台，内部涉及到自动化运维的一部分，趁着十一这两天玩过回来在学习expect，看tcl一章异常处理的时候，突然想到个问题，异常合理处理方式的问题。

异常合理从技术上分2种处理方式。

1、抛exception的方式；

2、返回值判断的方式；

其实任何系统中，都不可能只用一种处理方式，不然这个就过犹不及的，总结了一下比较合理的方式。

返回值判断的方式比较适合于正常逻辑的一部分，哪怕对于某个业务功能来说，它可能影响很大，比如文件不完整，账户不存在，密码不正确，金额为负数等。

抛异常则适合于出错了有可能无法继续往下运行的场景，比如配置文件不存在，数据库连接不上，网络断开。此时调用者必须仔细思考是否捕获异常，清一色往上抛是不负责的做法。

除此之外，有可能会出现的情况就是一个程序中有可能会抛出七八种异常，这个时候，如果都通过抛出异常的方式让外部捕获，这个实现就比较差了，而且并不一定所有的异常都是不可修复的。

还有很重要的一点，对于可能返回null的场景，内部没有检查是否为null，而是依赖于运行时的NullPointerException总觉得不是一种特别合理的方式。因为NullPointerException是个继承于RuntimeException，这使得异常捕获是可选的。真到运行时抛出很可能会导致业务中止而不一致。对于这个null，更合理的做法应该是对于逻辑已知有可能为null而导致外部调用者使用null返回值可能会异常的（比如DES/base64加解密），或许更好的方式是抛出一个包装的受检异常，强行要求外部调用者捕获，而不是外部调用者判断返回值是否为null（应用开发者很有可能是不会去看源码的），这可能是更好的方式。对于非open source程序，在自定义的受检异常上包装自定义的错误代码这会更加的清晰。