2

「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チェックスタイルルールに一致させることで、高速でクリーンかつ簡単な方法でどのように文書化できますか？

よろしくwnck

4

3 に答える 3

2

そうですね、Javadocを使用してSunCheckstyleルールに一致させることは不可能かもしれません。

これは、@inheritDocJavadocタグがコンストラクターで確実に機能しないためです（コンストラクターは継承できません）。@inheritDocまた、Checkstyleはコンストラクターを認識しません。代わりに、 Checkstyle構成を使用して、例外クラスのコンストラクターをJavadocMethod要件から除外するのが最善の策です。

後者は、 JavadocMethodチェックのtokensプロパティをjustに設定し、を省略することで実現できます。例外クラスの場合、例外には実際に説明が必要なメソッドが含まれていない可能性があるため、JavadocMethodチェックを完全に抑制することも理にかなっています。METHOD_DEFCTOR_DEF

于 2013-03-12T22:19:38.197 に答える
0

私はあなたがこのようなものを探していると思います：

/**
 * {@inheritDoc}
 */

これについては、http： //docs.oracle.com/javase/6/docs/technotes/tools/solaris/javadoc.html#@inheritDocで読むことができます。

于 2013-03-12T22:15:04.960 に答える
0

私の推奨事項は次のとおりです。少なくともこれらのコンストラクターについては、チェックスタイルでそのルールを無効にすることを検討してください。誰もが自分が何をしているのかを知っているか、これを簡単に調べることができます。実際に役立つドキュメントを提供することに力を注いでください。

于 2013-03-12T22:36:41.800 に答える