Parsing Exclusions
+ +The grammar for PLSQL used in PMD has several bugs and might not parse all DDL scripts +without errors. However, it should be best practice to call PMD for every DDL script. +Thus, we introduce the following workaround to cope with the situation.
+ +We introduce two special comments PMD-EXCLUDE-BEGIN and PMD-EXCLUDE-END
+which cause PMD to treat the source in between these comments more or less
+like a multi-line comment, or in other words, just not try to parse them.
It is good practice to include a reason for excluding inside the
+-- PMD-EXCUDE-BEGIN comment separated by a colon.
The PMD-EXCLUDE-BEGIN and PMD-EXLUDE-END comment lines must not contain
+other statements, e.g. do_xy(); -- PMD-EXCLUDE-BEGIN is invalid.
Example:
+ +begin
+ do_something();
+ -- PMD-EXCLUDE-BEGIN: PMD does not like dbms_lob.trim (clash with TrimExpression)
+ dbms_lob.trim(the_blob, 1000);
+ -- PMD-EXCLUDE-END
+ do_something_else();
+end;
+The existence of exclusions can be detected with the attributes
+ExcludedRangesCount and ExcludedLinesCount of the top-level ASTInput node.
+If nothing is excluded, both values are 0 (zero).
+Otherwise, ExcludedRangesCount contains the number of excluded line-ranges
+and ExcludedLinesCount is the total number of excluded lines.
+A future version of PMD might pass the line excluded line ranges,
+source fragments and the corresponding reason comments
+as child nodes of the top-level ASTInput node.
In order to keep track where such parse exclusions are used, you could create +a custom XPath rule with the following expression:
+ +/Input[@ExcludedRangesCount > 0]
+This will find all files with at least one excluded range.
+ + + + + + +