up next

Introduction

Whenever an error occurs in Smalltalk/X, the system enters a debugger (*). It is also possible, to enter the debugger via the "halt"-message, which is understood by every object. Try evaluating:
    self halt
in a workspace.
To open a workspace for that, press:
Finally, pressing "CNTL-C" in any view stops the corresponding process and opens a debugger on it.

The debugger may run in one of three modes:

The Debugger consists of 4 major subviews plus some action buttons;

(the actual appearance of the Debugger depends on the viewStyle setting; the picture above was taken with the "iris-style" in effect)

the subviews are:

  1. context walkback list
  2. method source view
  3. receiver inspector
  4. context inspector

The context walkback list shows the context chain which lead to the error (i.e. starting at the current context on top, the list of senders is displayed).

Selecting a context in this list will show the corresponding methods source in the method source view, with the current line highlighted.

The recevier inspector allows inspection of the receiver of the selected message and the context inspector provides information about the arguments and local variables of this context.

The method source view highlights the current position of execution.
This view is a codeView - which means that you can change the code and "accept" to change the method (i.e. fix errors and compile). However, once accepted, the source code of the method is no longer in sync with the state of the process (since that one is still suspended in the previous, old code).
To avoid confusion, the debugger hides all stack frames up to and including the one in which the accept occurred.

Footnotes

(*) this is a bit oversimplified. Actually, all errors raise a signal, which then (if not handled) opens the debugger. Thus the behavior on those errors is actually under the programmers control.
Doc $Revision: 1.12 $ $Date: 1998/03/06 15:32:24 $