How Do I ... : Test and debug my application : Debug my scripts : Find the coding error : Find errors in scripts that run okay, but give incorrect results
Find errors in scripts that run okay, but give incorrect results
Look at the attribute values of objects used by my applicationLook at the attribute values of objects used by my applicationNo tips for this topicNo example for this topicFix the coding errorFix the coding error
If your code runs without opening a debugger but returns the wrong answer, there are two ways to debug the problem: add a halt to your code or set a breakpoint in the script. After adding a halt or breakpoint to your code, you can use the debugger to see what scripts and objects your code is using.
Adding a halt
For example, suppose you want to see what scripts and objects are used for code that defines a small dictionary. Insert halt or self halt in the code so it looks like the following:
(Dictionary new)
at: 1 put: 'Sam';
at: 2 put: 'Mary';
at: 3 put: 6;
at: 9 put: (Date today);
Next, run the code (highlight it and select Inspect).
Adding a breakpoint
Instead of using halt, you can add a breakpoint in your script. To add a breakpoint, do the following:
1. Open a browser such as a Script Editor on your code.
2. Position the cursor where you want to insert a breakpoint.
You cannot insert a breakpoint in a Doit method. Nor can you set a breakpoint on entry to a primitive method; however, breakpoints are supported in primitive fail code.
3. Select Break from the Edit or Breakpoints menu.
4. In the Configure Breakpoints window displayed, specify constraints on the breakpoint. One Shot specifies if the breakpoint should remove itself after the first time it is triggered. Stop in process defines the processes in which the breakpoint should fire. Stop at iteration defines how often many times a breakpoint can be hit in a process before the breakpoint fires. Stop when true defines a Smalltalk expression that causes a breakpoint to fire if it evaluates to true; the expression can use local and temporary variables.
For most breakpoints, you will likely want to take the defaults of for the process and iteration constraints and true for the expression constraint.
5. Select OK.
The breakpoint is highlighted and a dot appears beside the browser's description pane.
For example, use a script such as TestMonth below to try a breakpoint.
"Print month values for Month drop-down
list (m1) and DateMonth (m2) text field."
| m1 m2 |
m1 := (self subpartNamed: 'Month') object.
m2 := (self subpartNamed: 'DateMonth') object.
Transcript cr; show: m1 printString.
Transcript cr; show: m2 printString.
After a debugger opens, select the message that caused the error from the message stack (middle-left pane). For this example, select UndefinedObject>>#Doit. Notice that halt is highlighted in the bottom pane. Now, individually select the push buttons in the middle of the debugger. They offer four ways of stepping through the code:
Displays the source code of the method sent next.
Runs the method sent next without displaying the method's source code.
Runs the code and stops only if it finds an error in one of the messages in the message stack. This is the fastest way to step through code.
Causes the process to continue until it completes.
Last modified date: 08/12/2019