В общем случае чем сложнее ошибка, тем сложнее код для подтверждения ошибки .Лексеры и парсеры довольно просты (на практике) и поэтому ловят простые ошибки.
- Лексеры ловят недопустимые последовательности символов, которые должны составлять маркер
- синтаксический анализ инструменты, такие как Bison / Yacc, отлавливают недопустимые последовательности токенов, составляющих синтаксис и операторов.
Сложные ошибки обычно происходят в другом месте во время выполнения или в различных переводах во время компиляции.Примеры могут включать ссылку на функцию / метод, который не существует.Области закрытия / привязка, идентификаторы объектов и ссылок, достоверность аргументов, перегрузка и множество других зависимых от языка вещей.
Все, что находится за пределами этой очень узкой области действия токенов / синтаксиса, находится (или должно обрабатываться) далеко за пределами этих инструментов вАнализ AST или генерация промежуточного кода.
Рассмотрим:
a.b();
ab();
Оба должны сделать это через лексер / синтаксический анализатор для объектно-ориентированного языка, где оба оператора являются допустимыми. есть ли ошибка?
Ваш компилятор может утверждать это в время компиляции , если язык довольно статический и идентификаторы могут быть разрешеныво время компиляции.
Вы можете заменить оба оператора кодом разрешения идентификатора, который будет выполняться при время выполнения , чтобы вызвать ошибку времени выполнения, а не ошибку компилятора.
Различия между временем выполнения и разрешением во время компиляции и семантикой могут быть тонкими и сильно различаться от языка к языку.
Обычно ошибки обнаруживаются, когда они могут быть известными как ошибки и где у вас больше всего информации.Это зависит от языка и реализации.