第7章 错误处理
错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法。
使用异常而非返回码。
他们搞乱了调用者代码。调用者必须在调用之后即刻检查错误，而这个步骤很容易被遗忘。
在某种意义上，try代码块就像是事务。catch代码块将程序维持在一种持续状态。
可控异常的代价就是违反开放/闭合原则。
你得在catch语句和抛出异常处之间的每个方法签名中声明该异常。
这意味着对软件中较低层级的修改，都将波及较高层级的签名。
可控异常有时也会有用：在那些关键代码库的地方，你必须捕获异常。
你抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和处所。
应创建信息充分的错误消息，并和异常一起传递出去。在消息中，包括失败的操作和失败类型。
当我们在应用程序中定义异常类时，最重要的考虑应该是它们如何被捕获。
将第三方API打包是个良好的实践手段。
当你打包一个第三方API，你就降低了对它的依赖。
打包的好处还在于你不必绑死在某个特定厂商的API设计上。
别返回null值。
返回null值，基本上是在给自己增加工作量，也是在给调用者添乱。
只要有一处没检查null值，应用程序就会失控。
别传递nul值。
除非API要求你向它传递null值，否则就要尽可能避免传递null值。
在大多数编程语言中，没有良好的方法能对付由调用者意外传入的null值。
恰当的做法就是禁止传入null值。
整洁代码是可读的，但也要强固。
可读与强固并不冲突。
如果将错误处理隔离看待，独立于主逻辑之外，就能写出强固而整洁的代码。
单独处理错误，极大地提升了代码的可维护性。