This section describes the advanced built-in predicates for creating and removing breakpoints.
Here, both Tests and Actions are either a simple
Condition, see Breakpoint Conditions, or a composite
Condition. Conditions can be composed by forming lists, or by
using the ‘,’, ‘;’, ‘->’, and ‘\+’ operators,
with the usual meaning of conjunction, disjunction,
if-then-else, and negation, respectively. A list of conditions is
equivalent to a conjunction of the same conditions
] is treated as
add_breakpoint/2 predicate performs some
transformations and checks before adding the breakpoint. All
condition macros invoked are expanded into their bodies, and this
process is repeated for the newly introduced bodies. The
pred conditions are then extracted from the outermost
conjunctions of the test part and moved to the beginning of
the conjunction. If these are inconsistent, a consistency error is
signalled. Module name expansion is performed for certain tests,
as described below.
Both the original and the transformed breakpoint spec is recorded
by the debugger. The original is returned in
current_breakpoint/5, while the transformed spec is used in
determining the applicability of breakpoints.
There can only be a single plain spypoint for each predicate. If a plain spypoint is added, and there is already a plain spypoint for the given predicate, then:
)to the test part of Spec, for each predicate Pred designated by the generalized predicate spec PredSpec. See mpg-ref-spy.
off, referring to enabled and disabled breakpoints. Kind is one of
generic, where MFunc is the module qualified functor of the specific breakpoint. Type is the breakpoint type:
current_breakpoint/5 enumerates all breakpoints on
The Spec as returned by
current_breakpoint/5 is exactly the
same as supplied at the creation of the breakpoint.
advice. The atoms specify all breakpoints, debugger type breakpoints and advice type breakpoints, respectively.
truecondition. Otherwise only those tests can be used, which query the data stored in the backtrace. An exception is raised if the latter condition is violated, i.e. a non-backtraced test (see Breakpoint Conditions) occurs in a call of
execution_state/1from outside the debugger.
Note that the predicate arguments holding a breakpoint
spec (Spec or Tests above) are subject to module name
expansion. The first argument within simple tests
inherit the module name from the (module name expanded)
breakpoint spec/tests predicate argument, if there is
no explicit module qualification within the simple test. Within
) command value settings, Old will
get the module name from the
by default, while New from the whole breakpoint spec
The following hook predicate can be used to customize the behavior of the interactive debugger.
Note that if a line typed in response to the debugger prompt cannot
be parsed as a debugger command,
called with the term
Line is the code-list typed in, with any leading whitespace
Warning is a warning message. This allows the user
to define new debugger commands, see Hooks Related to Breakpoints
for an example.