If a groovy file contains a \ after the closing brace for the class, the org.codenarc.rule.formatting.SpaceAfterClosingBraceRule blows up with an ArrayIndexOutOfBoundsException. (This may or may not be appropriate. I am not sure if that should be considered a bug or not - but its not the bug I care about)
The problem I see is that Ant swallows this exception, and continues to process other source files, and just ignores the fact that it blew up trying to anayze a groovy file. I believe it would be much better for the ant build to fail immediately because a file in its analsis set is unable to be analyzed.
I have attached a tar project that contains 2 groovy files. One file has the ending backslash and the other file does not. Other than their class names and the ending slash, the files are identical.
There is an included ant build.xml that shows that the bad file is completely skipped and there is no indication at all that codenarc experienced an issue when trying to analyze a file.
Thanks for the feedback and detailed problem report.
The main reason that CodeNarc ignores those processing errors is that CodeNarc is built against a certain version of Groovy, and so may not be able to parse Groovy files with newer language constructs/AST. But I can look into making that behavior configurable.
We'll have to treat SpaceAfterClosingBraceRule error as a separate issue.
Thanks for your response. Do you want me to open the issue about the SpaceAfterClosingBraceRule error? Or has that already been done?
Yes, please do open an issue about the SpaceAfterClosingBraceRule error.
Re: making the ignore vs fail behavior for parsing errors configurable. Those errors happen on a separate thread, and so failing the Ant Task on parsing errors would require a non-trivial redesign.
Is the parsing error that you encountered even valid groovy code (e.g. the backslash following the closing brace)? My original thinking was that syntax/compiler errors would end up getting caught when the code was compiled, and so I was not going to worry too much about that -- but perhaps that was too optimistic. I do acknowledge that there is some subset of parsing errors for which it would be beneficial for CodeNarc to notify/fail.