<<
>>

Подробнее об обработке ошибок

Имеется еще одна важная проблема, которую стоит отметить: обработка ошибок. Обратите внимание, что хотя синтаксический анализатор правильно отбрасывает (почти) каждое некорректное выражение, которое мы ему подбросим, со значимым сообщением об ошибке, в действительности мы не слишком много поработали для того, чтобы это происходило.

Фактически во всей программе (от Ident до Expression) есть только два вызова подпрограммы обработки ошибок Expected. Но даже они не являются необходимыми… если вы посмотрите снова на процедуры Term и Expression, то увидите, что эти утверждения не выполнятся никогда. Я поместил их сюда ранее для небольшой подстраховки, но сейчас они более не нужны. Почему бы не удалить их сейчас?

Но как мы получали такую хорошую обработку ошибок фактически бесплатно? Просто я тщательно старался избежать чтения символа непосредственно используя GetChar. Взамен я возложил на GetName, GetNum и Match выполнение всей обработки ошибок для меня. Проницательные читатели заметят, что некоторые вызовы Match (к примеру в Add и Subtract) также не нужны… мы уже знаем чем является символ к этому времени… но их присутствие сохраняет некоторую симметрию, и было бы хорошим правилом всегда использовать Match вместо GetChar.

Выше я упомянул «почти». Есть случай, когда наша обработка ошибок оставляет желать лучшего. Пока что мы не сказали нашему синтаксическому анализатору как выглядит конец строки или что делать с вложенными пробелами. Поэтому пробел (или любой другой символ, не являющийся частью признаваемого набора символов) просто вызывает завершение работы анализатора, игнорируя нераспознанные символы.

Можно рассудить, что в данном случае это приемлемое поведение. В «настоящем» компиляторе обычно присутствует еще одно утверждение, следующее после того, с которым мы работаем, так что любой символ, не обработанный как часть нашего выражения, будет или использоваться или отвергаться как часть следующего.

Но это также очень легко исправить, даже если это только временно. Все, что мы должны сделать – постановить, что выражение должно заканчиваться концом строки, то есть, возвратом каретки.

Чтобы понять о чем я говорю, испробуйте входную строку:

1+2 3+4

Видите, как пробел был обработан как признак завершения? Чтобы заставить компилятор правильно отмечать это, добавьте строку

if Look CR then Expected('Newline');

в основную программу, сразу после вызова Expression. Это отлавливает все левое во входном потоке. Не забудьте определить CR в разделе const:

CR = ^M;

Как обычно откомпилируйте программу и проверьте, что она делает то, что нужно.

<< | >>
Источник: Креншоу Джек. Давайте создадим компилятор!. 1999

Еще по теме Подробнее об обработке ошибок:

  1. Очень подробно представьте себе, как все происходит.
  2. МЕТОД ПРОБ И ОШИБОК
  3. Источниками ошибок являются
  4. 13. Не бойтесь исправления своих ошибок
  5. ИЗБАВЬТЕСЬ ОТ СВОИХ ОШИБОК, А НЕ ПОВТОРЯЙТЕ ИХ
  6. Выводы. Если вы хотите, чтобы он достиг успеха - остерегайтесь этих ошибок
  7. ИНФОРМАЦИЯ: ОБРАБОТКА ПОСЛЕДОВАТЕЛЬНАЯ (
  8. ИНФОРМАЦИЯ: ОБРАБОТКА ПАРАЛЛЕЛЬНАЯ
  9. Статистическая обработка.
  10. ТЕОРИЯ УРОВНЕЙ ОБРАБОТКИ
  11. Обработка материалов
  12. Обработка результатов
  13. ГЛАВА ДЕВЯТАЯ ОБРАБОТКА ИНФОРМАЦИИ В УМЕ
  14. Обработка ответов
  15. Алгоритм обработки результатов.
  16. ДАННОЕ: ОБРАБОТКА СТАТИСТИЧЕСКАЯ
  17. Обработка материала