I create a lot of exception classes, extending "Exception" and creating all constructors matching the constructors of the superclass "Exception". Eclipse generates this:
/**
*
*/
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
}
}
I don't want to document all param tags because the constructors just match semantically the constructors of the base class.
How can this fact be documented in a fast, clean and simple way using javadoc AND matching the SUN checkstyle rules?
Regards wnck
Well, I'm afraid it may not be possible using Javadoc and matching the Sun Checkstyle rules.
This is because the @inheritDoc
Javadoc tag does not reliably work with constructors (they are not inheritable). Also, Checkstyle does not recognize @inheritDoc
on constructors. Instead, your best bet would be to exclude the constructors of your exception classes from the JavadocMethod requirement using Checkstyle configuration.
The latter could be achieved by setting the tokens
property of the JavadocMethod check to just METHOD_DEF
and omitting CTOR_DEF
. For exception classes, it may also make sense to simply suppress the JavadocMethod check entirely, as exceptions probably don't contain any methods that really need explaining.