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.
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 more seldom, but still occasionally happening are FileNotFound exceptions, typically occuring with file open operations.
There could even still be codeGenerator bugs in the compiler
and even crashes of the support system (Virtual Machine).
But, luckily, these are relatively 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 intermediate values.
Remember, that the "abort" action in the debugger brings you right back into an applications
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 write operations in the ST/X system are aware of possible errors
and will keep a backup version of a file which is being overwritten).
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.
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.
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
".
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:
Copyright © 2003 eXept Software AG, all rights reserved
<info@exept.de>
Doc $Revision: 1.12 $ $Date: 2009/09/21 13:52:21 $