描述一个方法所抛出的异常,是正确使用这个方法时所需文档的重要组成部分。因此,花点时间仔细地为每个方法抛出的异常建立文档是特别重要地。
始终要单独地声明受检异常
,并且利用Javadoc的@throws标签,准确的记录下抛出每个异常的条件
。如果一个公有方法可能抛出多个异常类,则不要使用快捷方式声明它会抛出这个异常类的某个超类。永远不要声明一个公有方法直接throws Exception
或者更糟糕的是声明它直接throws Throwable
,这是非常极端的例子。这样的声明不仅没有为程序员提供关于“这个方法能够抛出哪些异常”的任何指导信息,而且大大的妨碍了该方法的使用,因为它实际上掩盖了该方法在同样的执行环境下可能抛出的任何其他异常。这条建议有一个例外,就是main方法,它可以被安全的声明抛出Exception,因为它只通过虚拟机调用。
虽然Java语言本身并没有要求程序员为一个方法声明它可能会抛出的未受检异常,但是,如同受检异常一样,仔细的为他们建立文档是非常明智的。未受检异常通常代表编程上的错误(详见第70条),让程序员了解所有这些错误都有助于帮助他们避免犯同样的错误。对于方法可能抛出的未受检异常,如果将这些异常信息很好的组织成列表文档,就可以有效的描述出这个方法被成功执行的前提条件。每个方法的文档应该描述它的前提条件(详见第56条),这是很重要的,在文档中记录下未受检异常是满足前提条件的最佳做法*。
对于接口中的方法,在文档中记录下它可能抛出的未受检异常显得尤为重要。这份文档构成了该接口的通用约定的一部分,它指定了该接口的多个实现必须遵循的公共行为。
使用Javadoc的@throws标签记录一个方法可能抛出的每个未受检异常,但是不要使用throws关键字将未受检的异常包含在方法的声明中
。使用API的程序员必须知道哪些异常是需要受检的,哪些是不需要受检的,因为他们有责任区分这两种情形。当缺少由throws声明产生的方法标头时,由Javadoc的@throws标签所产生的文档就会提供明显的提示信息,以帮助程序员区分受检异常和未受检异常。
应该注意的是,为每个方法可能抛出的所有未受检异常建立文档是很理想的,但是在实践中并非总能做到这一点。当类被修订之后,如果有个导出方法被修改了,它将会抛出额外的未受检异常,这不算违反源代码或者二进制兼容性。假设一个类调用了另一个独立编写的类中的方法。第一个类的编写者可能会为每个方法抛出的未受检异常仔细地建立文档,但是,如果第二个类被修订了,抛出了额外的未受检异常,很有可能第一个类(它并没有被修订)就会把新的未受检异常传播出去,尽管它没有声明这些异常。
如果一个类中的许多方法出于同样的原因而抛出同一个异常,在该类的文档注释中对这个异常建立文档,这是可以接受的
,而不是为每个方法单独建立文档。一个常见的例子是NullPointerException。若类的文档注释中有这样的描述:“All methods in this class throw a NullPointerException if a null object reference id passed in any paramerer(如果在任何参数中传递了空对象引用,则此类中的所有方法都会引发NullPointerException)”,或者有其他类似的语句,这是可以的。
总而言之,要为你编写的每个方法所能抛出的每个异常建立文档。对于未受检异常和受检异常,以及抽象的方法和具体的方法一概如此。这个文档在文档注释中应当采用@throws标签的形式。要在方法的throws子句中为每个受检异常提供单独的声明,但是不要声明未受检的异常。如果没有为可以抛出的异常建立文档,其他人就很难或者根本不可能有效的使用你的类和接口。
网友评论