![[up]](../icons/DocsUpArrow.gif){kind=icon}
|
To err is human.
We are human. |
This page is meant to give you a guideline on what should be done when an error happens and how they should be reported to others.
First: Don't be afraid - Don't panic.
Smalltalk in general is pretty robust.
That means, that bugs usually only have local effects.
Even if some functionality in an application
has a defect, other parts of the system and usually also other parts
of the buggy application are not affected, and continue to function.
Another class of bugs is related to assuming that something is in a container, which is not. I.e. when accessing a dictionary ("no such element"-bug) or when removing from an already empty container.
A bit more subtle are index bugs - often resulting from a previous search, which failed to find an element (and the bad index which is usually 0 is then used).
Although very seldom, but still occasionally happening are FileNotFound exceptions.
There could even still be code generator bugs in the compiler
and even crashes of the support system (Virtual Machine).
But, luckily, these are very very rare.
Interestingly, wrong type errors (i.e. sending a message to some object which it does not implement) are actually very rare (except for the UndefinedObject case above). This is in contrast to what many advocates of static typed languages promote.
A bug is proceedable, if it occurred in some notifier, message output, or draw function.
You should abort, if the bug produces followup errors
(due to missing or wrong intermediate and return values).
Remember, that the "abort" action in the debugger brings you right back into an application's
main event handling loop - whatever action it was currently executing, will be aborted.
That means: if it was performing a menu action, that menu action is aborted;
if it was handling a keyStroke, that processing is aborted; and if it was doing a redraw,
the redraw will be aborted.
Of course, whatever function it was performing will not be completed and you will see a partially
drawn window, or a partially performed menu-function's result.
If the error happened during a file-write operation, that file may now be incomplete and
contain garbage - be careful to not loose any data.
Most of the file-write operations in the ST/X system are aware of possible errors
and will either keep a backup version of the file which is being overwritten,
or first write into a new temporary file and rename that at the end,
when the actual write has finished with success.
So you should either have a backup version of the file around,
or the original file unchanged.
If your own program writes files, it is a good idea to use this strategy as well,
because there is a non-zero chance for such failures, even if ST/X and
your program work well
(power failure, system crash/shutdown, communication failures,
user interrupts etc.).
In some (rare) situations, the application in which the error occurred is corrupt
(due to some internal state, which is now bad) and errors continue to pop up.
One example is an invalid value (typically nil) which is used in a window's redraw
operation. This will open a debugger whenever the view is about to be drawn,
and again, when the debugger is closed and the window is uncovered.
In that case, you should try to save any modified data and close that window
(not ST/X as a whole), reopen the application and try again.
If the application window does not react to a click on the close-icon,
open a Process Monitor and terminate the application thread there.
There is also a menu function in the launcher ("Select window and destroy"), which lets you click on any window on the screen and close/destroy it. This menu function is especially useful to close windows which have somehow lost their window event handling thread.
In very rare situations, the whole system is corrupted and the only chance is to restart
ST/X from the last snapshot. Thus it is useful to save snapshots from time to time.
However, be sure that you don't write a snapshot of an already corrupted image over
your previous (good) image file. A good strategy is to use names such as "stN.img",
with N counted up. When you are certain that the state saved in "stN.img" was a good one,
you can ocasionally remove older snapshots.
To start ST/X with one of your previous snapshots,
enter "smalltalk -i stN.img".
The snapshot save utility keeps the previous snapshot image as "st.bak" around,
which is sometimes helpful (to start ST/X with this backup-snapshot, enter "smalltalk -i st.bak").
st.img"
and then starting ST/X, or by telling ST/X to ignore the image with the -I flag as in "stx -I".
In addition to full snapshots, there is also a "Save Session Changes" option in the Launcher's file-menu. Open a change-browser on that, if you have a session-change-file available.
Smalltalk systems are meant to be used, modified and adjusted. As opposed to closed systems, where you MUST call for and wait for bug fixes, Smalltalk is open and you are free to change things, and fix bugs right away.
However, in order for us to be able to handle bug reports efficiently, we would like to ask you to include the following information in all bug reports:
![[stx-logo]](../icons/stx.gif){kind=icon}
Copyright © 2003 eXept Software AG, all rights reserved
<info@exept.de>