Error Production Strategy (Syntax Parsing Engine)

This topic explains the error production error handling strategy.

The following topics are prerequisites to understanding this topic:

This topic contains the following sections:

If a grammar writer identifies a common error that users are likely to type, he or she can define a non-terminal symbol to represent that error and then use it as an alternative to the structure(s) which the user likely meant to use. Then the grammar writer can set the NonTerminalSymbol.IsError value to True on that symbol. When parsing a document with no errors, the parser will make no attempt to reduce a production body to a non-terminal symbol that is marked as an error. It will be as if the non-terminal symbol was never defined. But as soon as an error occurs, the error production error handling strategy will look to see if any error non-terminal symbols could have reduced if given the chance. If so, those reductions are performed and the node created to represent the error non-terminal symbols are automatically marked as errors.

For example, in C# it is common for a user to start typing a member in a class but to pause long enough for the parser to start analyzing the document before they are finished. So the grammar writer might want to define a non-terminal symbol with the following pseudo-production:

IncompleteMember → [Attributes] [Modifiers] Type

And then they might use it in a place where other members are used:

ClassMember →

FieldDeclaration | MethodDeclaration | PropertyDeclaration | IncompleteMember

Now if the user were to type something such as this

In C#:

The error production strategy would detect an "IncompleteMember" could be created and the grammar writer could provide a custom error message saying "Incomplete member definition in class or struct".

This is much better than letting the synchronizer symbol strategy handle the error, because it would probably generate error messages such as

Although this is arguably correct, the strategy is guessing that the user was about to type a field declaration, simply because that produced the simplest tree structure for the missing nodes. The user could have easily been typing a property or method declaration.

The following topics provide additional information related to this topic.