Checkstyle Bug - "Got an exception - java.lang.RuntimeException: Unable to get class information for @throws tag 'DUSException'".(?) and Solution

Was in the code review phase last week... time for checkstyle, findbugs n PMD to come out!

Since it was a new project, with a little tinkering of a half-working Hudson ant script someone was working on, I could generate my Review reports. My checkstyle task was like below:
<target name = "checkstyle">
<mkdir dir="${checkstyle.report}"/>
<taskdef resource="checkstyletask.properties" classpath ="${checkstyle.home}/checkstyle-all-4.4.jar;${checkstyle.home}/checkstyle-optional-4.4.jar" />
<checkstyle config="${basedir}\..\settings\CheckstyleSettings.xml" failonviolation="false">
<fileset dir="${src.java.dir}" includes="**/*.java"/>
<formatter type="xml" toFile="${checkstyle.report}\checkstyle_errors.xml"/>
</checkstyle>

<style in="${checkstyle.report}\checkstyle_errors.xml" out="${checkstyle.report}\checkstyle_report.html"
style="${basedir}\..\settings\checkstyle.xsl"/>
</target>

Unfortunately, the Checkstyle Reports kept giving a strange Error in some classes:
"Got an exception - java.lang.RuntimeException: Unable to get class information for @throws tag 'DUSException'." at Line 0.
Classes which had this error would have no other Errors although the Warnings were not affected.

However, in my Eclipse editor with Checksyle Plugin and the same Checkstyle settings, I would get normal Checkstyle Errors and Warnings without thie Error.

Clearly, this was some Checkstyle runtime error and not an error in my class which resulted in Checkstyle failing to process that class for Errors.

Searched the net and came up with lots of explanations / bug accusations that made a lot of sense but no easy solution... Checkstyle was somehow missing out the DUSException class when it was encountered in a throws tag of a methods Javadoc.

So i decided to manually add my source class files to the classpath... and it worked!
<checkstyle config="${basedir}\..\settings\CheckstyleSettings.xml" failonviolation="false">
<classpath>
<path location="${classes.dir}" />
<path refid="code-lib-classpath" />
</classpath>
<fileset dir="${src.java.dir}" includes="**/*.java"/>
<formatter type="xml" toFile="${checkstyle.report}\checkstyle_errors.xml"/>
</checkstyle>

Unfortunately, the Checkstyle report started showing the real CS Errors and they doubled! :) But the team could finally tackle 'em bugs before they slipped to the next phase...


Strange thing was that most of the (new) team was also getting the same Checkstyle Bug in Eclipse... which was what made me assume that it really was a CS Bug.
Until I had a look at their CS preferences and found that they were applying CS on .java files only. Once it was changed to apply to all files, the issue was resolved in their Eclipse as well