At various places in the development of a Dezyne component errors can occur. This page provides an overview of the error categories, and some advice on their resolution.
Errors are either syntax or semantics oriented. A slightly different separation is made here however: Some errors can be found statically, by analyzing the text, other errors are found only during verification or simulation.
The static analysis of a component is done in a couple of phases. Each of these can report errors.
As a first step a Dezyne file is parsed and processed by a syntax checker. Modern parsers are generated from a high level specification and as a result all error messages are generated too. These error messages can be somewhat cryptic.
The next step involves name resolution: all declarations have to introduce a unique name and all identifiers that are used in a model have to be declared. Name resolution can be elaborate at some points, especially due to the use of 'dotted names', as in 'bool b = Intf.Result.Ok' where 'Ok' is an enum value introduced in the declaration of enum 'Result', which is introduced in the context of interface 'Intf'.
A typical error message would be:
identifier declared before: 'b'
undefined Enum value reference: 'OOK' in 'I.Result.OOK'
Once all names have been resolved, each expression is checked for type safety. An example:
In 'bool b = C && D' it is checked that 'C && D' is a 'bool' expression, and consequently that both 'C' and 'D' are 'bool' expressions. A typical error message would be:
'&&' requires a boolean second argument
On top of the above, a collection of well-formedness checks is defined. Some of these checks are 'common sense', other ones are needed to define appropriate semantics.
See Well-formedness for an overview of all checks.