On Tue, Oct 25, 2016 at 1:53 PM, Jochen Theodorou <blackd...@gmx.org> wrote:
> Hi,
>
> I am looking a bit into the usage of our old parser and keeping in mind
> the new parser we want to eventually make the default.
>
> But one problem I talked about in the past already is the direct usage of
> antlr2 types in something else than the parser itself. Moving the current
> parser into a subproject has the nice effect of highlighting those
> problems, since anltr2 classes are then not automatically part of the main
> module anymore.
>
> And then you find things like this:
>
> if (cause instanceof NoViableAltException) {
>> return isEofToken(((NoViableAltException)
>> cause).token);
>> } else if (cause instanceof NoViableAltForCharException) {
>> char badChar = ((NoViableAltForCharException)
>> cause).foundChar;
>> return badChar == CharScanner.EOF_CHAR;
>> } else if (cause instanceof MismatchedCharException) {
>> char badChar = (char) ((MismatchedCharException)
>> cause).foundChar;
>> return badChar == CharScanner.EOF_CHAR;
>> } else if (cause instanceof MismatchedTokenException) {
>> return isEofToken(((MismatchedTokenException)
>> cause).token);
>> }
>>
>
> The cause is from a SyntaxErrorMessage (actually cause is the cause of the
> cause). Basically this tells me we are lacking the capability to handle
> this case with only groovy-core classes. For the sake of compatibility I
> don´t think we should get rid of the cause, but extend SyntaxError(Message)
> or SyntaxException to support the transport of the missing information.
>
> I could now try to make a single class to cover all of the cases above,
> which means a token (maybe expecting) and foundChar (maybe expectedChar)
> and the problem, that if I have a token I do not have a char and vice
> versa. I could work with Char...
>
> if I want to project the given case and use the classic subclassing
> approach I would produce two new subclasses of SyntaxException. If I wanted
> to support the expected token or char, it would be 4 classes.
>
> Any opinions on that?
>
>
Could the existing "org.codehaus.groovy.syntax.TokenMismatchException"
cover the cases for "NoViableAltException" and "MismatchedTokenException"
(or maybe all cases since the focus is on finding unexpected EOF)?
