Debugging without a debugger

There is no step debugger. No breakpoints, no watching a variable change. What you have is logging, the diagnostic log viewer, and a method. LOGGING IS THE PRIMARY TOOL, and it is more effective than it sounds if the messages are designed. Log the rule name, the record identifier, and the values of the fields the rule depends on. Two messages — one at entry with the inputs, one at the decision point with the outcome — answer most questions, because between them they say whether the rule fired, on which record, and what it saw. The log viewer is where those appear, and the practical difficulty is volume: a rule on a busy object produces a great deal of output. Put a distinctive marker in every message — a short prefix per rule — so you can find yours among everything else. THE METHOD FOR ISOLATING WHICH RULE FIRED,…

In this module: Module 13 · Groovy in Application Composer

1. 1Where Groovy runs, and where it does not
2. 2The language subset, quickly
3. 3Validation rules that help rather than annoy
4. 4Triggers and the order they fire in
5. 5Object functions and reuse
6. 6Performance: the rule that runs a million times
7. 7Debugging without a debugger
8. 8What breaks: three Groovy failures
9. 9Lab briefing · A rule, and its performance