高效Java(第三版) Effective Java
1. 考虑使用静态工厂方法替代构造方法 2. 当构造方法参数过多时使用builder模式 3. 使用私有构造方法或枚类实现Singleton属性 4. 使用私有构造方法执行非实例化 5. 使用依赖注入取代硬连接资源 6. 避免创建不必要的对象 7. 消除过期的对象引用 8. 避免使用Finalizer和Cleaner机制 9. 使用try-with-resources语句替代try-finally语句 10. 重写equals方法时遵守通用约定 11. 重写equals方法时同时也要重写hashcode方法 12. 始终重写 toString 方法 13. 谨慎地重写 clone 方法 14. 考虑实现Comparable接口 15. 使类和成员的可访问性最小化 16. 在公共类中使用访问方法而不是公共属性 17. 最小化可变性 18. 组合优于继承 19. 如果使用继承则设计,并文档说明,否则不该使用 20. 接口优于抽象类 21. 为后代设计接口 22. 接口仅用来定义类型 23. 优先使用类层次而不是标签类 24. 优先考虑静态成员类 25. 将源文件限制为单个顶级类 26. 不要使用原始类型 27. 消除非检查警告 28. 列表优于数组 29. 优先考虑泛型 30. 优先使用泛型方法 31. 使用限定通配符来增加API的灵活性 32. 合理地结合泛型和可变参数 33. 优先考虑类型安全的异构容器 34. 使用枚举类型替代整型常量 35. 使用实例属性替代序数 36. 使用EnumSet替代位属性 37. 使用EnumMap替代序数索引 38. 使用接口模拟可扩展的枚举 39. 注解优于命名模式 40. 始终使用Override注解 41. 使用标记接口定义类型 42. lambda表达式优于匿名类 43. 方法引用优于lambda表达式 44. 优先使用标准的函数式接口 45. 明智审慎地使用Stream 46. 优先考虑流中无副作用的函数 47. 优先使用Collection而不是Stream来作为方法的返回类型 48. 谨慎使用流并行 49. 检查参数有效性 50. 必要时进行防御性拷贝 51. 仔细设计方法签名 52. 明智而审慎地使用重载 53. 明智而审慎地使用可变参数 54. 返回空的数组或集合不要返回null 55. 明智而审慎地返回Optional 56. 为所有已公开的API元素编写文档注释 57. 最小化局部变量的作用域 58. for-each循环优于传统for循环 59. 熟悉并使用Java类库 60. 需要精确的结果时避免使用float和double类型 61. 基本类型优于装箱的基本类型 62. 当有其他更合适的类型时就不用字符串 63. 注意字符串连接的性能 64. 通过对象的接口引用对象 65. 接口优于反射 66. 明智谨慎地使用本地方法 67. 明智谨慎地进行优化 68. 遵守普遍接受的命名约定 69. 仅在发生异常的条件下使用异常 70. 对可恢复条件使用检查异常,对编程错误使用运行时异常 71. 避免不必要地使用检查异常 72. 赞成使用标准异常 73. 抛出合乎于抽象的异常 74. 文档化每个方法抛出的所有异常 75. 在详细信息中包含失败捕获信息 76. 争取保持失败原子性 77. 同步访问共享的可变数据 78. 避免过度同步 79. EXECUTORS, TASKS, STREAMS 优于线程 80. 优先使用并发实用程序替代wait和notify 81. 线程安全文档化 82. 明智谨慎地使用延迟初始化 83. 不要依赖线程调度器 84. 其他替代方式优于Java本身序列化 85. 非常谨慎地实现SERIALIZABLE接口 86. 考虑使用自定义序列化形式 87. 防御性地编写READOBJECT方法 88. 对于实例控制,枚举类型优于READRESOLVE 89. 考虑序列化代理替代序列化实例

文档化每个方法抛出的所有异常

Tips
书中的源代码地址:https://github.com/jbloch/effective-java-3e-source-code
注意,书中的有些代码里方法是基于Java 9 API中的,所以JDK 最好下载 JDK 9以上的版本。

74. 文档化每个方法抛出的所有异常

描述方法抛出的异常,是正确使用方法所需文档的重要部分。因此,花时间为每个方法抛出的所有异常建立文档是非常重要的(条目 56)。

始终单独声明检查异常,并使用Javadoc @throw标签,精确地记录每次抛出异常的条件。不要使用“快捷方式”声明一个方法抛出它可以抛出的多个异常类的超类。作为一个极端的例子,不要声明公共方法抛出Exception类,或者更糟,抛出Throwable类。除了拒绝向方法的用户提供关于它能够抛出的异常的任何指导之外,这样的声明还极大地阻碍了方法的使用,因为它极大掩盖了可能在相同上下文中抛出的任何其他异常。这个建议的一个例外情况是main方法,它可以安全地声明为抛出Exception类,因为它只被虚拟机调用。

虽然Java语言不要求程序员声明方法能够抛出的未检查异常(unchecked exceptions),但明智的做法是像检查异常一样仔细地在文档中记录它们。未检查异常通常表示编程错误(条目 70),让程序员熟悉他们可能犯的所有错误可以帮助他们避免犯这些错误。方法可以抛出的未检查异常的良好文档列表有效地描述了成功执行的先决条件。每个公共方法的文档都必须描述它的先决条件(条目 56),记录它的未检查异常是满足这个需求的最佳方法。

特别重要的是,接口中的方法要在文档中记录它们可能抛出的未检查异常。此文档构成接口通用约定的一部分,并支持接口的多个实现之间的公共行为。

使用Javadoc @throw标签记录方法可以抛出的每个异常,但是不要对未检查的异常使用throws关键字。重要的是,使用你的API的程序员必须知道哪些方法是检查异常,哪些是未检查异常,因为程序员的责任在这两种情况下有所不同。Javadoc @throws标签生成的文档在方法声明中没有对应的抛出子句,这向程序员提供了一个强烈的视觉暗示,说明该异常是未检查异常。

应该注意的是,在文档中记录每个方法可以抛出的所有未检查异常是理想的,在现实世界中并不总是可以实现。当类进行修订时,如果将导出的方法修改为抛出额外的未检查异常,这并不违反源代码或二进制兼容性。假设一个类从另外一个独立编写的类调用一个方法。第一个类的作者可能会仔细记录所有的每个方法抛出未经检查的异常,但是如果第二个类的作者修改为额外的未经检查的异常,很可能第一个类(未经修订)将传播新的未经检查异常,尽管没有文档记录它们。

如果一个类中的许多方法出于相同的原因引发异常,可以在类的文档注释中记录异常,而不是为每个方法单独记录异常。一个常见的例子是NullPointerException。类的文档注释可以这样说:“如果在任何参数中传递了null对象引用,该类中的所有方法都会抛出NullPointerException”,或者类似的描述。

总之,在文档中记录你所编写的每个方法可能引发的每个异常。对于未检查异常、检查异常以及抽象方法和具体实现方法中都是如此。这个文档应该在文档注释中采用@throws标签的形式。在方法的throws子句中分别声明每个检查异常,但不要声明未检查异常。如果未记录方法可能抛出的异常,其他人将很难或不可能有效地使用你的类和接口。