JavaCC не соответствует правильным токенам во время обработки ошибок

#java #javacc

#java #javacc

Вопрос:

У меня возникли некоторые проблемы с использованием этого конкретного метода для решения проблем в моем анализаторе. Это мой код, представленный на Java:

 void handleErrors(Exception e, int kind, String strError) {
  //ParseException e = generateParseException();
  System.err.println("Errore nel parsing: <"   strError   ">");
  System.err.println(e.toString());
  Token t;

  do {
    t = getNextToken();
  } while(t.kind != kind amp;amp; t!=null amp;amp; t.kind != EOF );
}
  

Что-то идет не так, когда я пытаюсь проанализировать это простое объявление функции (сделайте ссылку на документацию AutoIt)

 Func askjd ($cas)
  

анализатор должен выдать исключение, сообщающее мне, что что-то не так с объявлением моей функции, но в нем указаны только общие предложения, такие как:

 ParseException: Encountered <EOF> at line 1, column 18.
Was expecting one of:
    "If" ...
    "For" ...
    "While" ...
    "Do" ...
    "Switch" ...
    "Func" ...
    "Return" ...
    "EndFunc" ...
    "Const" ...
    <VARNAME> ...
    <NAMEFUNC> ...
  

Он должен сказать мне, что EndFunc отсутствует ТОЛЬКО один, а не другие токены

Комментарии:

1. Судя по журналу, мне кажется, что ваш метод вообще не вызывается.

2. Метод вызывается правильно, потому что, если я раскомментирую код System.err .., он показывает мне ошибку при синтаксическом анализе: <» strError «>»

3. Откуда handleErrors вызывается? Вызывается ли он из вашего кода в файле .jj? Если это так, вы должны показать нам соответствующие продукты.

4. Кстати, код t.kind != kind amp;amp; t!=null выглядит неправильно, поскольку второе соединение никогда не может принять значение false.

5. Также вы говорите, что «Он должен сказать мне, что EndFunc отсутствует ТОЛЬКО один, а не другие токены». Если вы написали код для генерации такого сообщения, вы его нам не показали. Сгенерированный generateParseException JavaCC метод вычисляет набор всех допустимых токенов next. Я не знаю AutoIt, но, очевидно, если EndFunc бы это был единственный законный токен next, это был бы не очень полезный язык.