|
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 happened in some notifyer, message output function or draw function.
You should abort, if the first 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 functions result.
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 dont write a snapshot of an already corrupted image.
The snapshot save utility keeps the previous snapshot image as "st.bak" around, which
is occasionally helpful (to start st/x with this backup-snapshot, enter "smalltalk -i st.bak").
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.6 $