No side effects, no surprises.

Trip-point emitter

The trip-point emitter is called whenever an object fails to meet all validation rules. Its role is to gather all of the necessary information about the object's V language rules and the referent object's state, and to send a formatted message to the console, or the VLI log file, describing the situation.

Each message sent by a module identifies the rule that failed, and when applicable, provides both the expected value and the actual value that tripped the validation rule.

The trip-point emitter can also be configured to include four additional pieces of contextual information:

  1. The name of the source code file, and the line number within the file, of the rule that failed, using the output_line_number keyword.
  2. The scoping name and base name of the composed object that failed, using the output_object_name keyword.
  3. An optional comment, if it has been defined for the object by the rulebook developer, using the output_comment keyword.
  4. The internal name of the module's validation method—and the value of any parameters to that method—that tripped the validation rule, using the output_method keyword.

Some objects can be specified to include a very large number of referent objects. If each of these referent objects trips, the console could be flooded with messages. The output_limit keyword can be configured to quench messages when too many occur.

Rulebooks can also be configured to trace the entry and exit times of all objects with the runtime_trace keyword.

This example shows how a rulebook might be configured during development to show maximum diagnostic output:

rulebook-options
output_line_number = true
output_object_name = true
output_comment = true
output_method = true
output_limit = false
runtime_trace = true

While a rulebook is being developed it is useful to have many of these trip-point options turned on. Later, when a rulebook has been in production for a while and the system is running smoothly, it may be convenient to turn some of these options off. In this latter case, the VLI can be set to run at regularly scheduled times, quietly performing its validations without producing any output. In this quiet mode, the system administrator can "set it and forget it", receiving alerts only when a validation rule is tripped.