ExTLA.Invariant.Violation exception (ExTLA v0.6.0)

A Layer 1 property that did not hold, and what to do about it.

The struct is the report; report!/2 decides its fate from the mode the instrumented module was compiled under (ExTLA.Config.mode/0):

:enabled — raise. The default in dev and test, where a violated invariant is a bug and stopping at it is the point.
:log_only — log and continue. For staging, where the process surviving matters more than the report being unmissable.
:disabled — never reached: the mode emits no wrapper at all, so nothing calls this.

The message is the product

A violation that says "invariant :balance_non_negative does not hold" leaves the reader to diff the state by eye. This renders the state, and for an action property both states with the changed variables marked — the same reasoning as ExTLA.Trace.format/1, which is where a Layer 2 counterexample gets its worth.

Summary

Types

t()

Functions

report!(violation, mode \\ :enabled)

Report a violation, according to the mode the module was compiled under.

Types

t()

@type t() :: %ExTLA.Invariant.Violation{
  __exception__: term(),
  args: tuple() | nil,
  message: String.t(),
  module: module(),
  name: atom(),
  old_state: map() | nil,
  state: map(),
  type: :invariant | :action_property | :precondition | :postcondition
}

Functions

report!(violation, mode \\ :enabled)

Report a violation, according to the mode the module was compiled under.