Menu
▾
▴
1 Attachments
#399 MismatchedTokenException crash on parse error
When the Checkstyle parser detects a parse error, the exception is not caught by the Eclipse Checkstyle Plug-in, and thus the editor crashes.
See attachment for the error that are logged to the Eclipse Error log.
I think the error should instead be reported to the text editor, by adding an error marker.
The behaviour will be changed in the upcoming version 6.14.0.
If a exception is thrown from the Checkstyle engine it will be logged to the Eclipse error log as before, additionally an error marker will be added at project level - notifying the user of the failure.
The error dialog will not be displayed anymore in this case.
Unfortunately Eclipse still has no facilities for growl-like notifications, this would have been ideal for notifying the user without need for blocking error dialog windows.
See https://sourceforge.net/p/eclipse-cs/git/ci/399_checkstyle_error_handling/ for details
The change seems like a good start, for internal errors in general. IMHO, using error markers is much less intrusive than error dialogs or even popup notifications.
However, I don't think parse errors should be internal errors. I don't believe removing all other markers from the project is a good idea in that case. I also don't think a general internal error message indicates what is really going on, for parse errors. I think the parse error should be reported for that specific source file/resource, at the specific offset or line/column at which it happened, with the original parse error message.
I don't know that much about the internals of Checkstyle, so I can't tell whether this can be handled as a special case. However, it looks like checking the causes of a CheckstyleException to see whether it contains at some level a MismatchedTokenException, might do the trick. It looks like MismatchedTokenException is from ANTLR, and contains line/column information etc that could be used for this.
I also think that if a file has a parse error, checking should continue for the other files in the project. Not sure whether this is possible though.
Unfortunately I am constrainted by the way Checkstyle handled errors internally.
At the moment (this behaviour was changed a few releases back) any unexpected exception within Checkstyle is being wrapped and bubbled up to the caller (e.g. eclipse-cs). At this point the checking process is already interrupted.
Before Checkstyle 6.9 the behaviour was a you describe in your last paragraph, which had it's own sort of problems, apparently (difficulties getting to the stack trace information).
If you're interested in this topic you could take it up with the developers over at the Checkstyle project.
From the plugin developer perspective what you've seen in the patch is likely the best that can be done currently.
Implemented as described in release 6.14.0