.SH7: Error Handling.PPError handling is an extremely difficult area, and many of the problems are semantic ones.When an error is found, for example, it may be necessary to reclaim parse tree storage,delete or alter symbol table entries, and, typically, set switches to avoid generating any further output..PPIt is seldom acceptable to stop all processing when an error is found; it is more useful to continuescanning the input to find further syntax errors.This leads to the problem of getting the parser ``restarted'' after an error.A general class of algorithms to do this involves discarding a number of tokensfrom the input string, and attempting to adjust the parser so that input can continue..PPTo allow the user some control over this process,Yacc provides a simple, but reasonably general, feature.The token name ``error'' is reserved for error handling.This name can be used in grammar rules;in effect, it suggests places where errors are expected, and recovery might take place.The parser pops its stack until it enters a state where the token ``error'' is legal.It then behaves as if the token ``error'' were the current lookahead token,and performs the action encountered.The lookahead token is then reset to the token that caused the error.If no special error rules have been specified, the processing halts when an error is detected..PPIn order to prevent a cascade of error messages, the parser, afterdetecting an error, remains in error state until three tokens have been successfullyread and shifted.If an error is detected when the parser is already in error state,no message is given, and the input token is quietly deleted..PPAs an example, a rule of the form.DSstat	:	error.DEwould, in effect, mean that on a syntax error the parser would attempt to skip over the statementin which the error was seen.More precisely, the parser willscan ahead, looking for three tokens that might legally followa statement, and start processing at the first of these; ifthe beginnings of statements are not sufficiently distinctive, it may make afalse start in the middle of a statement, and end up reporting asecond error where there is in fact no error..PPActions may be used with these special error rules.These actions might attempt to reinitialize tables, reclaim symbol table space, etc..PPError rules such as the above are very general, but difficult to control.Somewhat easier are rules such as.DSstat	:	error  \';\'.DEHere, when there is an error, the parser attempts to skip over the statement, butwill do so by skipping to the next \';\'.All tokens after the error and before the next \';\' cannot be shifted, and are discarded.When the \';\' is seen, this rule will be reduced, and any ``cleanup''action associated with it performed..PPAnother form of error rule arises in interactive applications, whereit may be desirable to permit a line to be reentered after an error.A possible error rule might be.DSinput	:	error  \'\en\'  {  printf( "Reenter last line: " );  }  input			{	$$  =  $4;  }.DEThere is one potential difficulty with this approach;the parser must correctly process three input tokens before itadmits that it has correctly resynchronized after the error.If the reentered line contains an errorin the first two tokens, the parser deletes the offending tokens,and gives no message; this is clearly unacceptable.For this reason, there is a mechanism thatcan be used to force the parserto believe that an error has been fully recovered from.The statement.DSyyerrok ;.DEin an actionresets the parser to its normal mode.The last example is better written.DSinput	:	error  \'\en\'			{	yyerrok;				printf( "Reenter last line: " );   }		input			{	$$  =  $4;  }	;.DE.PPAs mentioned above, the token seen immediatelyafter the ``error'' symbol is the input token at which theerror was discovered.Sometimes, this is inappropriate; for example, anerror recovery action mighttake upon itself the job of finding the correct place to resume input.In this case,the previous lookahead token must be cleared.The statement.DSyyclearin ;.DEin an action will have this effect.For example, suppose the action after errorwere to call some sophisticated resynchronization routine,supplied by the user, that attempted to advance the input to thebeginning of the next valid statement.After this routine was called, the next token returned by yylex would presumablybe the first token in a legal statement;the old, illegal token must be discarded, and the error state reset.This could be done by a rule like.DSstat	:	error 			{	resynch();				yyerrok ;				yyclearin ;   }	;.DE.PPThese mechanisms are admittedly crude, but do allow for a simple, fairly effective recovery of the parserfrom many errors;moreover, the user can get control to deal withthe error actions required by other portions of the program.