Button Functions

Continue

Continue execution
The process continues execution where it was stopped originally. If the code has been changed in the debugger (i.e. "accepted"), the old, original code is executed until the same message is sent again. Only then would any changed code be executed.

Abort

Abort the current activity (if possible)
This function raises the AbortSignal, which is cought by most processes at some save place.
For example, workspaces catch this signal while executing a 'doIt' expression, thus "abort" will abort that execution and return to the workspace's input handling. If in a file browser while filing in (loading) code, the filein is aborted. Finally if aborted in any window while the event dispatcher processes an event, this event's processing is aborted, and the next event is handled (or waited for).
Thereforem pressing 'Abort' will usually break out and return to a save place.

Typically, this is equivalent to a resume of the corresponding handler context's sender.

Most often, this is the recommended action to take, in order to exit the debugger after an error has been encountered, especially after code has been fixed in the debugger and resend is not possible due to already changed state.

This is also the action taken by the debugger if its main window is closed.

Terminate (Process)

Terminate the erroneous process.
This is a soft terminate, in that the process gets a chance to perform its cleanup actions (aka "unwind"; see ``stack unwinding and signal handling''). If the process is controlling a view (i.e. a window group process), all of its windows are closed. Therefore, this should only be used if the above "Abort" fails. Because it usually terminates the underlying application, you may loose changes done in that application (for example, if it is a browser or text editor).

Because this is considered to be a "dangerous operation", the corresponding button is shown in a red color.

However, sometimes you need this if an error reappears over and over, for example if an error is present in a window's event handling code and an abort leads immediately to another error, to get out of such a never ending story.
This function is disabled in a modal debugger (because this would terminate the event dispatcher or scheduler).

Report By Mail

Send an email to exept.
If an error persists, and it is not an error which resulted from an invalid configuration, from bad input or from one of your own changes, you may want to (indeed, you should) press this button to send an email notification to the Smalltalk/X maintenance group at eXept.
The dialog asks you to enter additional information or a friendly hello-message to the mail's body text, and also to adjust any sender information. When you click on the send button, an email providing stack-walkback info is sent to eXept.

Depending on the settings, this function may not be present as a button function. In that case, you should look in the "File"-menu. However, it will be disabled, if no SMPT mail-host has been configured in the Launcher's "Settings"-"Communication"-"Misc" dialog.

Next

Single step for next sourceline
Let the process continue execution, until the current source line number changes in the selected context. The implementation of single stepping is based on hooking into the message send mechanism of the underlying runtime system. Therefore, non-message sends (i.e. assignments and inlined if-constructs) are skipped and cannot be single stepped. Due to the implementation, single stepping may be a bit slow, if many computations are done in the stepped method (for each send, the process is interrupted and the debugger gets informed and checks for the current send to determine whether it should be shown). This slow stepping is only done within the stepped context - any code called by it is not single stepped and runs a full speed. Unless another halt or breakpoint is encountered, the debugger gets back control when either the current line has changed or the context was returned from (either explicitly or via an unwind or process termination).
This function is not available for inspecting debuggers.

Step

Single step for send in this method
Let the process continue execution, until the next message send is performed in the selected context. Read the notes above for details on single stepping.
This function is not available for inspecting debuggers.

Send

Single send
Let the process continue execution for one message send - showing every message send. In contrast to the above stepping functions, this will also single step through every other method called (i.e. it is stepping into the called method).
This function is not available for inspecting debuggers.

Resend

Resend the message
Unwinds the stack and resends the message to the receiver of the selected context.

This is one of the most useful functions, and typically used after a code change in the debugger. Apply this after a change made to a method (for example, one which was halted or breakpointed) and the method did not change any state on which it depends. Resending is not useful for example, if the method did already read data from a file stream or changed some other object. Then the called method would likely see unexpected/wrong data and fail for other reasons. In this case, select a context higher up in the calling chain (for example, where the file was opened) and restart that context, or use the "Abort" button, and retry the changed code in a "fresh run".

Notice: due to some compiler optimizations, not every context may be restartable. The button is disabled if such a context is selected.

Return

Return from this context
continue execution as if the selected context returned - effectively "jumping out" and returning from this context (i.e. simulate a '^ nil' from a selected method context, or return nil from a block evaluation).
If there is a selection in the codeview, which forms a valid expression, that value is used as return value. Otherwise, nil is returned to its sender.

Notice: in the current ST/X implementation, this function cannot be performed on block contexts or on method contexts which have been compiled with certain compiler-optimizations enabled. The "Return"-button is disabled if such a context is selected.

The bad news is that most precompiled classes have been compiled with this stc compiler optimization. So in fact most contexts of the base system are non-returnable. A workaround is to recompile the corresponding classes using the browser's "Recompile all Methods" menu item before you start to debug, to get "unoptimized" versions of those methods. Another workaround is to move up in the caller chain until you find any "returnable" context.

Restart

Restart this context
continue execution by restarting the selected context. (this is now more or less obsoleted by the "resend" button).

Notice: in the current ST/X implementation, this function cannot be performed on block contexts or on method contexts which have been compiled with certain compiler-optimizations enabled. The "Restart"-button is disabled if such a context is selected.

Read the notice above for workarounds.

Goto Dialog Opener

Find and select the code which opened the dialog
This button is only shown if the process is stopped while a modal dialog is open. It searches the caller chain for the method which is opened the dialog and selects it. This is very useful to quickly navigate to your code after you interrupted it while inside an open dialog. Try it after pressing "CMD-." while a search dialog is shown ("CMD-s").

Goto Application Method

Find and select the application code which is responsible for the error
This button is only shown if the process is stopped due to an error in an application. It searches the caller chain for the method which initialted the current activity and selects it. This is very useful to quickly navigate to your code after you hit an error in a lower level (called) method. For example, if a stream read error exception is raised deeply nested down in a stream class, this brings you quickly to the place in your own program were the file operation was issued in the first place (the actual file operation).

Goto Raising Method

Find and select the code which was responsible for the exception
This button is only shown if the process is stopped due to an unhandled exception (such as a "doesNotUnderstand"). It searches the caller chain for the method which is responsible for the exception-raise and selects it.

Notice, that the debugger usually already tries to show the location of the error, if entered due to an unhandled exception. However, this button is useful to quickly navigate to the next raise-location for example, if interrupted while inside an exception handler which either raised another exception or which presented a warning dialog.

Goto UnitTest Method

Find and select the responsible unit test method.
This button is only shown if the process is stopped while executing a testcase from a unit test suite. It searches the caller chain for the test method and selects it.

Define Method

Generates the missing method and resend the message
This button is only shown if the process is stopped due to a message not understood exception. It creates (generates, compiles and installs) the missing method as a debugging stub method and resends the message so that the fresh method is entered. There, it will stop again due to a halt message. This is very useful to interactively and incrementally implement missing functionality of an application. Programmers usually develop missing functions by pressing this button, and let the program proceed into the just created method. There, the missing code can be written incrementally, by editing, accepting and resending, until the code works as desired.

Continue in "Menu Functions"...

Copyright © 1995 Claus Gittinger Development & Consulting, all rights reserved