Парсеры (и, следовательно, механизмы, предоставляемые генераторами парсеров) должны иметь какое-то средство для обработки недопустимых исходных файлов. Таким образом, каждый синтаксический анализатор (и генератор синтаксического анализатора) выбрал некоторый метод для управления синтаксическими ошибками.
Самое простое решение, предлагаемое большинством, - просто вызвать исключение при возникновении такой ошибки. Код пользователя, вызывающий синтаксический анализатор, должен перехватить это исключение и использовать прерванный анализ. Более сложное решение - синтаксический анализатор сообщает о синтаксической ошибке, но восстанавливается после ошибки и продолжает синтаксический анализ; любое такое восстановление должно обрабатывать сборку AST с каким-то маркером на узлах в точке ошибки, если вы также надеетесь получить пригодное для использования дерево. Большинство генераторов синтаксических анализаторов предлагают какое-то восстановление синтаксиса, но оставляют вас наедине, чтобы справиться с AST, создавая лицо таких ошибок. Такую логику восстановления синтаксического анализатора создать довольно сложно, и вы, вероятно, не сможете сделать это самостоятельно, если не станете экспертом по восстановлению синтаксических анализаторов и внесете пользовательские изменения в код поддержки конкретного генератора синтаксического анализатора.
Я не совсем знаком с JavaCC (или большинством других генераторов синтаксических анализаторов), поэтому не знаю, так ли это. Очевидно, проверьте документы. Если нужной вам поддержки обработки ошибок нет, перейдите к другому генератору, у которого она есть.
Я подозреваю, что вашей настоящей проблемой будет получение грамматики, подходящей для вашей задачи. Ни у кого нет "Java" или "COBOL"; у них есть определенный диалект, например, Java 1.5 или IBM Enterprise COBOL или VB6. Они более отличаются от воображаемого базового языка, который вы ожидаете, основываясь на моем долгом опыте. Вы можете надеяться, что такие грамматики, которые вы можете получить, будут работать (включая восстановление после ошибок), чтобы позволить вам анализировать различные диалекты каждого, несмотря на такие различия, но, как правило, вы получите большое количество ошибок из кода на одном диалекте, который не не соответствует грамматике вы хотите. (Что вы будете делать с номерами карт после столбца 72 в вашем коде IBM Enterprise COBOL, в котором есть исходные файлы EBCDIC?) Итак, вам действительно нужен инструмент с множеством синтаксических анализаторов, которые обрабатывают различные диалекты, и который должен определять ваш выбор ИМХО.
Я думаю, ANTLR имеет много определений языка (больше, чем JavaCC), так что это как бы подходит. Тем не менее, многие грамматики на этом сайте являются экспериментальными или незаконченными (некоторые довольно хороши), так что вам повезло.
Наш инструментарий реинжиниринга программного обеспечения DMS содержит много грамматик , и мы считаем своей задачей обеспечить качество продукции. Мы тоже не идеальны, но наши грамматики, как правило, тестировались на больших объемах кода и имеют поддержку различных диалектов. Встроено восстановление после ошибок, и вы получите дерево назад (с узлами ошибок в AST), если число ошибок меньше указанного порогового значения. DMS также обрабатывает неприятные проблемы, такие как кодирование символов (мы делаем большое разнообразие, включая EBCDIC с 80 столбцами и номерами карт в столбце 72 для IBM COBOL и JCL). DMS может быть не тем, что вы хотите; например, он не основан на Java. Но мы стараемся восполнить это, предоставляя огромное количество оборудования для поддержки задач после разбора, таких как то, что вы хотите сделать. Этот механизм включает в себя поддержку построения таблиц символов, извлечения потоков управления и данных, сопоставления шаблонов и применения преобразований источник-источник и т. Д. Но это компромисс для вас.