share/doc/psd/15.yacc/ss7

   1 .\" Copyright (C) Caldera International Inc. 2001-2002.  All rights reserved.
   2 .\"
   3 .\" Redistribution and use in source and binary forms, with or without
   4 .\" modification, are permitted provided that the following conditions are
   5 .\" met:
   6 .\"
   7 .\" Redistributions of source code and documentation must retain the above
   8 .\" copyright notice, this list of conditions and the following
   9 .\" disclaimer.
  10 .\"
  11 .\" Redistributions in binary form must reproduce the above copyright
  12 .\" notice, this list of conditions and the following disclaimer in the
  13 .\" documentation and/or other materials provided with the distribution.
  14 .\"
  15 .\" All advertising materials mentioning features or use of this software
  16 .\" must display the following acknowledgement:
  17 .\"
  18 .\" This product includes software developed or owned by Caldera
  19 .\" International, Inc.  Neither the name of Caldera International, Inc.
  20 .\" nor the names of other contributors may be used to endorse or promote
  21 .\" products derived from this software without specific prior written
  22 .\" permission.
  23 .\"
  24 .\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA
  25 .\" INTERNATIONAL, INC.  AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR
  26 .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
  27 .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  28 .\" DISCLAIMED.  IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE
  29 .\" FOR ANY DIRECT, INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR
  30 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  31 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
  32 .\" BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
  33 .\" WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
  34 .\" OR OTHERWISE) RISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
  35 .\" IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  36 .\"
  37 .\"     @(#)ss7 8.1 (Berkeley) 6/8/93
  38 .\"
  39 .\" $FreeBSD$
  40 .SH
  41 7: Error Handling
  42 .PP
  43 Error handling is an extremely difficult area, and many of the problems are semantic ones.
  44 When an error is found, for example, it may be necessary to reclaim parse tree storage,
  45 delete or alter symbol table entries, and, typically, set switches to avoid generating any further output.
  46 .PP
  47 It is seldom acceptable to stop all processing when an error is found; it is more useful to continue
  48 scanning the input to find further syntax errors.
  49 This leads to the problem of getting the parser ``restarted'' after an error.
  50 A general class of algorithms to do this involves discarding a number of tokens
  51 from the input string, and attempting to adjust the parser so that input can continue.
  52 .PP
  53 To allow the user some control over this process,
  54 Yacc provides a simple, but reasonably general, feature.
  55 The token name ``error'' is reserved for error handling.
  56 This name can be used in grammar rules;
  57 in effect, it suggests places where errors are expected, and recovery might take place.
  58 The parser pops its stack until it enters a state where the token ``error'' is legal.
  59 It then behaves as if the token ``error'' were the current lookahead token,
  60 and performs the action encountered.
  61 The lookahead token is then reset to the token that caused the error.
  62 If no special error rules have been specified, the processing halts when an error is detected.
  63 .PP
  64 In order to prevent a cascade of error messages, the parser, after
  65 detecting an error, remains in error state until three tokens have been successfully
  66 read and shifted.
  67 If an error is detected when the parser is already in error state,
  68 no message is given, and the input token is quietly deleted.
  69 .PP
  70 As an example, a rule of the form
  71 .DS
  72 stat    :       error
  73 .DE
  74 would, in effect, mean that on a syntax error the parser would attempt to skip over the statement
  75 in which the error was seen.
  76 More precisely, the parser will
  77 scan ahead, looking for three tokens that might legally follow
  78 a statement, and start processing at the first of these; if
  79 the beginnings of statements are not sufficiently distinctive, it may make a
  80 false start in the middle of a statement, and end up reporting a
  81 second error where there is in fact no error.
  82 .PP
  83 Actions may be used with these special error rules.
  84 These actions might attempt to reinitialize tables, reclaim symbol table space, etc.
  85 .PP
  86 Error rules such as the above are very general, but difficult to control.
  87 Somewhat easier are rules such as
  88 .DS
  89 stat    :       error  \';\'
  90 .DE
  91 Here, when there is an error, the parser attempts to skip over the statement, but
  92 will do so by skipping to the next \';\'.
  93 All tokens after the error and before the next \';\' cannot be shifted, and are discarded.
  94 When the \';\' is seen, this rule will be reduced, and any ``cleanup''
  95 action associated with it performed.
  96 .PP
  97 Another form of error rule arises in interactive applications, where
  98 it may be desirable to permit a line to be reentered after an error.
  99 A possible error rule might be
 100 .DS
 101 input   :       error  \'\en\'  {  printf( "Reenter last line: " );  }  input
 102                         {       $$  =  $4;  }
 103 .DE
 104 There is one potential difficulty with this approach;
 105 the parser must correctly process three input tokens before it
 106 admits that it has correctly resynchronized after the error.
 107 If the reentered line contains an error
 108 in the first two tokens, the parser deletes the offending tokens,
 109 and gives no message; this is clearly unacceptable.
 110 For this reason, there is a mechanism that
 111 can be used to force the parser
 112 to believe that an error has been fully recovered from.
 113 The statement
 114 .DS
 115 yyerrok ;
 116 .DE
 117 in an action
 118 resets the parser to its normal mode.
 119 The last example is better written
 120 .DS
 121 input   :       error  \'\en\'
 122                         {       yyerrok;
 123                                 printf( "Reenter last line: " );   }
 124                 input
 125                         {       $$  =  $4;  }
 126         ;
 127 .DE
 128 .PP
 129 As mentioned above, the token seen immediately
 130 after the ``error'' symbol is the input token at which the
 131 error was discovered.
 132 Sometimes, this is inappropriate; for example, an
 133 error recovery action might
 134 take upon itself the job of finding the correct place to resume input.
 135 In this case,
 136 the previous lookahead token must be cleared.
 137 The statement
 138 .DS
 139 yyclearin ;
 140 .DE
 141 in an action will have this effect.
 142 For example, suppose the action after error
 143 were to call some sophisticated resynchronization routine,
 144 supplied by the user, that attempted to advance the input to the
 145 beginning of the next valid statement.
 146 After this routine was called, the next token returned by yylex would presumably
 147 be the first token in a legal statement;
 148 the old, illegal token must be discarded, and the error state reset.
 149 This could be done by a rule like
 150 .DS
 151 stat    :       error
 152                         {       resynch();
 153                                 yyerrok ;
 154                                 yyclearin ;   }
 155         ;
 156 .DE
 157 .PP
 158 These mechanisms are admittedly crude, but do allow for a simple, fairly effective recovery of the parser
 159 from many errors;
 160 moreover, the user can get control to deal with
 161 the error actions required by other portions of the program.