Smalltalk and Object Orientation: an Introduction - Free

Breakpoints may be placed in a me thod by using the halt breakpoint method. This can be used
with or without arguments. For example:
self halt. or self halt: 'An example breakpoint'.
This form of the halt message is useful if more than one breakpoint exists within the system as it
allows the breakpoint to be identified. For example, the result of executing the above halt message
expression is illustrated in Figure 15.1. Notice that, the dialog is actually entitled “Exception ”. This is
because both error messages and halts raise a signal which is caught by the exception handler. Notice,
that unlike the result of encountering an error message, the user can proceed after evaluating a halt
message.
Figure 15.1: An example breakpoint dialog
When a halt expression is encountered, the message halt is sent to the receiver. The corresponding
method is implemented in Object so all objects respond to it. This opens the halt notifier from which
point you can proceed as if the halt had never been encountered, terminate or select the debug option if
you wish to analyze the state of the object when the breakpoint was encountered. If the debug option is
selected then a debugger window is opened on the method currently executing.
Note that just like an error message, a halt message can be used anywhere that you would use any
other message expression. You can therefore conditionalize the call to halt:
(x < y)
ifFalse: [self halt].
15.3 File in/file outs
15.3.1 File out
It is possible to file out any group of definitions using the System Browser (or one of its derivatives).
That is, you can save to a file whole class categories, individual classes, whole method protocols or just
individual methods. By doing so you create a file on the host system’s file system, which contains a
plain ASCII definition of the appropriate class, method etc. To save information to file, select the file
out option in the appropriate browser window.
This ASCI I file can be viewed in the same way as any other ASCII file using one of the host
system’s editors / viewers (e.g. EMACS, vi or more on a UNIX system). However, if you do this, you
will notice that some additional characters have been added (these are “!” and used as delimiters) as
well as extra statements indicating that something is a class comment or a method protocol name etc.
Normally, you would not need to edit this file and indeed, unless you are sure of what you are doing,
you should not do so.
The purpose of creating “file outs” can be to provide a permanent storage for your class definitions
etc. or to share those definitions with others. If you have created a definition which is particularly
important and which you do not want to lose at any cost, it is often a good idea to file it. At least then, if
you have a catastrophic failure and have to create a whole new image on a new platform, you can still
reconstruct your important work.
Another reason for creating file outs, is that they take up a lo t less space than the system image.
Therefore, if you have a number of sets of definitions which you wish to retain, but not enough space to
123