home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V6 / usr / doc / yacc / ss5 < prev    next >
Encoding:
Text File  |  1975-06-26  |  6.1 KB  |  146 lines
  1. .SH
  2. Section 5: Error Handling
  3. .PP
  4. Error handling is an extremely difficult area, and many of the problems are semantic ones.
  5. When an error is found, for example, it may be necessary to reclaim parse tree storage,
  6. delete or alter symbol table entries, and, typically, set switches to avoid putting out any further output.
  7. .PP
  8. It is generally not acceptable to stop all processing when an error is found; we wish to continue
  9. scanning the input to find any further syntax errors.
  10. This leads to the problem of getting the parser ``restarted'' after an error.
  11. The general class of algorithms to do this involves reading ahead and discarding a number of tokens
  12. from the input string, and attempting to adjust the parser so that input can continue.
  13. .PP
  14. To allow the user some control over this process,
  15. Yacc provides a simple, but reasonably general, feature.
  16. The token name ``error'' is reserved for error handling.
  17. This name can be used in grammar rules;
  18. in effect, it suggests places where errors are expected, and recovery might take place.
  19. The parser attempts to find the last time in the input when the special
  20. token ``error'' is permitted.
  21. The parser then behaves as though it saw the token name ``error'' as an input token,
  22. and attempts to parse according to the rule encountered.
  23. The token at which the error was detected remains the next input token after this error token is processed.
  24. If no special error rules have been specified, the processing effectively halts when an error is detected.
  25. .PP
  26. In order to prevent a cascade of error messages, the parser assumes that, after
  27. detecting an error, it remains in error state until three tokens have been successfully
  28. read and shifted.
  29. If an error is detected when the parser is already in error state,
  30. no error message is given, and the input token is quietly deleted.
  31. .PP
  32. As a common example, the user might include a rule of the form
  33. .DS
  34. statement :  error ;
  35. .DE
  36. in his specification.
  37. This would, in effect, mean that on a syntax error the parser would attempt to skip over the statement
  38. in which the error was seen.
  39. (Notice, however, that it may be difficult or impossible to tell the end of a statement,
  40. depending on the other grammar rules).
  41. More precisely, the parser will
  42. scan ahead, looking for three tokens that might legally follow
  43. a statement, and start processing at the first of these; if
  44. the beginnings of statements are not sufficiently distinctive, it may make a
  45. false start in the middle of a statement, and end up reporting a
  46. second error where there is in fact no error.
  47. .PP
  48. The user may supply actions after these special grammar rules,
  49. just as after the other grammar rules.
  50. These actions might attempt to reinitialize tables, reclaim symbol table space, etc.
  51. .PP
  52. The above form of grammar rule is very general, but
  53. somewhat difficult to control.
  54. Somewhat easier to deal with are rules of the form
  55. .DS
  56. statement :  error \';\'  ;
  57. .DE
  58. Here, when there is an error, the parser will again attempt to skip over the statement, but in
  59. this case will do so by skipping to the next ``;''.
  60. All tokens after the error and before the next ``;'' give syntax errors, and are discarded.
  61. When the ``;'' is seen, this rule will be reduced, and any ``cleanup''
  62. action associated with it will be performed.
  63. .PP
  64. Still another form of error rule arises in interactive applications, where
  65. we may wish to prompt the user who has incorrectly input a line, and allow
  66. him to reenter the line.
  67. In C we might write:
  68. .DS
  69. inputline:    error \'\en\' prompt inputline
  70.     = { $$ = $4; };
  71.  
  72. prompt:    /* matches no input */
  73.     = {  printf( "Reenter last line: " ); };
  74. .DE
  75. There is one difficulty with this approach;
  76. the parser must correctly process three input tokens before it is prepared to
  77. admit that it has correctly resynchronized after the error.
  78. Thus, if the reentered line contains errors
  79. in the first two tokens, the parser will simply delete the offending tokens,
  80. and give no message; this is clearly unacceptable.
  81. For this reason, there is a mechanism in both C and Ratfor which
  82. can be used to force the parser
  83. to believe that resynchronization has taken place.
  84. One need only include a statement of the form
  85. .DS
  86. yyerrok ;
  87. .DE
  88. in his action
  89. after such a grammar rule, and the desired effect will take place;
  90. this name will be expanded, using the ``# define'' mechanism of C or
  91. the ``define'' mechanism of Ratfor, into an appropriate code sequence.
  92. For example, in the situation discussed above where we
  93. want to prompt the user to produce input,
  94. we probably want to consider that the
  95. original error has been recovered
  96. when we have thrown away the previous line, including the newline.
  97. In this case,
  98. we can reset the error state before putting out the prompt message.
  99. The grammar rule for the nonterminal symbol prompt becomes:
  100. .DS
  101. prompt:    /* matches no input */
  102.     = {
  103.         yyerrok;
  104.         printf( "Reenter last line: " );
  105.     } ;
  106. .DE
  107. .PP
  108. There is another special feature which the user may
  109. wish to use in error recovery.
  110. As mentioned above, the token seen immediately
  111. after the ``error'' symbol is the input token at which the
  112. error was discovered.
  113. Sometimes, this is seen to be inappropriate; for example, an
  114. error recovery action might
  115. take upon itself the job of finding the correct place to resume input.
  116. In this case,
  117. the user wishes a way of clearing the previous input token
  118. held in the parser.
  119. One need only include a
  120. statement of the form
  121. .DS
  122. yyclearin ;
  123. .DE
  124. in his action; again, this expands, in both C and Ratfor, to the appropriate
  125. code sequence.
  126. For example, suppose the action after error
  127. were to call some sophisticated resynchronization routine,
  128. supplied by the user, which attempted to advance the input to the
  129. beginning of the next valid statement.
  130. After this routine was called, the next token returned by yylex would presumably
  131. be the first token in a legal statement; we wish to throw away the
  132. old, illegal token, and reset the error state.
  133. We might do this by the sequence:
  134. .DS
  135. statement :  error 
  136.     = { 
  137.         resynch( );
  138.         yyerrok ;
  139.         yyclearin ;
  140.     } ;
  141. .DE
  142. .PP
  143. These mechanisms are admittedly crude, but do allow for a simple, fairly effective recovery of the parser
  144. from many errors, and have the virtue that the user can get ``handles'' by which he can deal with
  145. the error actions required by the lexical and output portions of the system.
  146.