Question

我创建了很多异常类，扩展了“Exception”并创建了与超类“Exception”的构造函数匹配的所有构造函数。 Eclipse生成了这个：

/**
 * 
 */
package pone.interfaces;


/**
 * @author wnck
 *
 */
public class FancyException extends Exception {

/**
 * 
 */
public FancyException() {
    // TODO Auto-generated constructor stub
}

/**
 * @param message
 */
public FancyException(String message) {
    super(message);
    // TODO Auto-generated constructor stub
}

/**
 * @param cause
 */
public FancyException(Throwable cause) {
    super(cause);
    // TODO Auto-generated constructor stub
}

/**
 * @param message
 * @param cause
 */
public FancyException(String message, Throwable cause) {
    super(message, cause);
    // TODO Auto-generated constructor stub
}

/**
 * @param message
 * @param cause
 * @param enableSuppression
 * @param writableStackTrace
 */
public FancyException(String message, Throwable cause,
        boolean enableSuppression, boolean writableStackTrace) {
    super(message, cause, enableSuppression, writableStackTrace);
    // TODO Auto-generated constructor stub
}
}

我不想记录所有param标记，因为构造函数只是在语义上匹配基类的构造函数。

如何使用javadoc和匹配SUN checkstyle规则以快速，简洁和简单的方式记录这一事实？

问候wnck

Answer 1

好吧，我担心使用Javadoc并匹配Sun Checkstyle规则可能无法实现。

这是因为@inheritDoc Javadoc标记不能可靠地与构造函数一起使用（它们不可继承）。此外，Checkstyle无法识别构造函数上的@inheritDoc。相反，您最好的选择是使用Checkstyle配置从 JavadocMethod 要求中排除异常类的构造函数。

后者可以通过将 JavadocMethod 检查的tokens属性设置为METHOD_DEF并省略CTOR_DEF来实现。对于异常类，完全简单地{{3>} JavadocMethod 检查也是有意义的，因为异常可能不包含任何真正需要解释的方法。

Answer 2

我认为你正在寻找这样的东西：

/**
 * {@inheritDoc}
 */

您可以在此处阅读：http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/javadoc.html#@inheritDoc

Answer 3

我的建议是：不要，并考虑至少在那些构造函数中禁用checkstyle中的规则。每个人都知道他们做了什么或者很容易看出来。尽力提供实际有用的文档。

有关checkstyle SUN约定的派生异常的最简单的javadoc文档？

3 个答案: