Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#253 Fails to get class info for exceptions


The warning-level problem shows up for any exception
defined as part of the compilation unit.

Sample problem description:
"Unable to get class information for

Relevant method signature:
/ ..
@throws InvalidMoveException if an invalid move is
public void moveTo(Pin target) throws
InvalidMoveException { ... }

The exception is defined in the same package.


  • Logged In: YES

    This is a known limitation of JavadocMethod check.
    To fix the problem you should add required classes to
    classpath for checkstyle.
    I'm closing the bug as not a bug. Feel free to reopen it if
    you think that this is another problem.

  • Logged In: YES

    The problem still happens if I specify the classes explicitly like
    so (note the -cp argument):

    java -cp "..\Towers Of Hanoi\bin" -jar f:\JAR\checkstyle-3.4
    \checkstyle-all-3.4.jar -c jf_checks.xml -p
    jf_toplevel.properties -o toh_checks -r "..\Towers Of

    See attached for the audit result.

    Now, if checkstyle would provide more details, what it is
    looking for and where it is looking, that would be helpful.

    Also, if this is a checkstyle programming limitation, I'd like to
    suggest that this kind of error is not listed as an audit line

    Please elaborate why you think that this is not a bug.

  • Logged In: YES

    You noted that module JavadocMethod is the culprit. It is
    actually module "RedundantThrows" that causes this problem.
    If I leave JavadocMethod active and remove
    RedundantThrows, then the problematic audit entries

  • Logged In: YES

    JavadocMethod and RedundantThrows checks both need classes
    for exceptions (I just
    thought that in this particular case JavadocMethod check
    throws suchh error)

    About specifying class path:
    if you do use -jar option than classpath is exactly the jar
    you provided, neither -cp nor
    CLASSPATH env. variable do not provide addiotional classes.
    To add something
    to classpath you should use -Xbootclasspath/a.

  • Logged In: YES

    Just closing this defect in the database does not fix it.

    If checkstyle can retrieve information for types, it can
    retrieve information for exceptions. It is clearly wrong that for
    a.b.CL and a.b.EX it can find class information for a.b.CL but
    not for a.b.EX, just because EX is an exception.

    If for some unexplained reason this isn't going to happen,
    then it is a documentation defect. The documentation must
    explain this limitation, which is severe enough to forgo the
    use of IllegalThrows and JavadocMethod for any project that
    defines its own exceptions.

  • Logged In: YES

    These checks need to know if a given exception is checked
    or not (subclass of RuntimeException and Error).
    The only way to get this information for Checkstyle is try to
    load class and check it. Thus we need these classes in
    Checkstyle classpath (appropriate notes added to
    documentation for both checks).
    BTW what does that means "checkstyle can retrieve
    information for types"? Why do you think that it can?

  • Lars Kühne
    Lars Kühne

    Logged In: YES

    Jrgen wrote: "Also, if this is a checkstyle programming
    limitation, I'd like to suggest that this kind of error is
    not listed as an audit line item."

    I agree with that, the problem is now tracked separately in
    bug #1048226.

  • Lars Kühne
    Lars Kühne

    Logged In: YES

    Jrgen, I think the problem is more severe with the
    commandline frontend, because it does not really provide a
    good way to specify the classpath, except for the
    bootclasspath hack Oleg mentioned (BTW, did that work for you?).

    Most people probably use the ant task, and there setting the
    classpath is no problem. You just need to make sure you
    compile your project before running checkstyle, and that can
    be handled by ant's dependency management.

    If you really intend to use the commandline frontend, would
    it be sufficient to add a "-projectclasspath" parameter to
    solve your problem?

  • Logged In: YES

    Actually, I use the Checkclips
    e plug-in
    of Checkstyle for Eclipse 3.0. I tried the
    command-line example only to make sure there's nothing
    funny going on inside of the IDE.

    With Checkclipse Checkstyle is executing each time a code
    change is made - just as it should be - compiling prior of
    checking would defeat the purpose of the plug-in.

    Having said that, Checkstyle should not rely on the boot
    classpath. Doing so is a questionable workaround at best.

    It is not obvious to me why exception class definitions should
    be different from other class definitions. If check-style is
    operating as a parser, then it should be able to parse the
    superclass(es) of exceptions. Alternatively it can use the
    Reflection API to find the superclass(es).

  • Lars Kühne
    Lars Kühne

    Logged In: YES

    OK, inside an eclipse plugin the bootclasspath trick will
    obviously not work.

    You said: "With Checkclipse Checkstyle is executing each
    time a code
    change is made - just as it should be - compiling prior of
    checking would defeat the purpose of the plug-in".

    I would question that. Checkstyle does not work on
    syntactically incorrect files, so Eclipse should first
    compile your java code, and only call checkstyle if
    compilation succeeded. Additionally, classes need to be
    compiled and checkstyle needs access to the class files
    before we can use the reflection API to analyse them (as you
    suggest and as we do for Exceptions)

    With the command line, letting checkstyle access the
    compiled classes is a bit tricky (involving the
    bootclasspath, and yes, we should change that), for the
    checkclipse plugin both prerequisites might not be
    satisfied. See also checkclipse release notes for version
    1.1.1 which talks about a problem with making the project
    classpath available to checkstyle, that classloader issue
    appearantly has never been fixed in later versions.

    Please notify the plugin author about this problem, we'd be
    happy to help him work out this issue.

    FYI exceptions are currently the only classes that we are
    trying to load from the classpath. All other elements are
    handled purely syntactically, we only analyse the Syntax
    tree of your java sources.

  • Logged In: YES

    I've committed fir for 1048226 into CVS for 4.0, thus I
    close this bug as fixed too