一些基本概念

1. 正常情况下，一个未被捕获的异常将会使线程终止，并打印出栈轨迹，但是，如果异常发生在一个终结函数中，则情形不会这样-甚至连警告都不会打印出来

 

2.要想区分一个设计良好的模块与一个设计不好的模块，最重要的因素是，这个模块对于外部的其它模块而言，是否隐藏了内部的数据和其它的实现细节。一个设计良好的模块会隐藏所有的实现细节，把它的API与实现清晰的隔离开来。然后，模块之间只通过它们的API进行通信，一个模块不需要知道其它模块的内部工作情况。这个概念被称为信息隐藏(information hiding)，或封装(encapsulation)，是软件设计的基本原则之一。

3.    “任何对参数的限制都是一件好事”不完全正确。相反，你在设计方法时，应该使它们尽可能通用，并切合实际的需要。假设一个方法对于它能接受的所有参数值都能够完成合理的工作，那么，你对于参数的限制应该是越少越好。然而，通常情况下，有些限制对于被实现的抽象来说是很本质的。

    总而言之，每当你编写一个方法或者构造函数的时候，应该考虑对于它的参数有哪些限制，你应该把这些限制写到文档中，并且在这个方法体的起始处，通过显示的检查来实施这些限制。养成这样的习惯是非常重要的；有效性检查所需要的适量工作从第一次合法性检查失败中就可以连本带利得到补偿。

 

4. 没有理由从一个取数组值的方法中返回null，而不是返回一个零长度数组

 

5. 将局部变量的作用域最小化，可以增加代码的可读性和可维护性，并降低出错的可能性。

 

6. 为连接n个字符串而重复地使用字符串连接操作符，需要n的平方级的时间。这是由于字符串是非可变的而导致的不幸结果。当两个字符串被连接的时候，它们的内容都要被拷贝。

 

7. 异常只应该被用于不正常的条件，它们永远不应该被用于正常的控制流

 

8. 总而言之，对于可恢复的条件，使用被检查的异常；对于程序错误，使用运行时异常

 

9. 三种可抛出结构：错误(Error), 运行时异常(RuntimeException、非检查异常), 非运行时异常(检查异常)

 

10.  如果期望调用者能够恢复，对于这样的条件应该使用被检查的异常

 

11. 运行时异常来指明程序错误。大多数的运行时异常都是表名前提违例。(运行时异常证明程序逻辑存在问题，必须修改)

 

12. 你所实现的所有的未被检查（运行时）的抛出结果都应该是RuntimeException的子类（直接的或者间接的）