[prev] [up] [next]

Error & Warning Messages

Overview & Contents

This document lists some (most?) of the error and warning messages from various parts of the system. A short explanation of what the message means, and what should be done is given for each.

Diagnostics produced by stc

When compiling with stc, error and warning messages may be either produced by stc itself, or by the c-compiler, during the second compilation phase.
Remember: stc first creates C-code as intermediate code, and calls the c compiler for machine code generation.

Stc-generated messages are of the form:

file.st, line n: msgType: some text

while messages produced by the C-compiler usually look like:

file.c, line n: msgType: some text

(of course, the details depend on the type of c-compiler used, so no more information can be given here).

There should be no error messages from the C-compiler, except in wrong defined primitive code. However, some C-compilers are more 'picky' than others and output warnings sometimes. These can usually be ignored (and stc will be fixed to output code which does not produce warnings).

The handling of some errors can be changed by stc command line arguments. Also, warning messages may be disabled. See the stc manual page for more info.

Stc error messages

variables

classes

syntax

checked semantic

For some receiver/selector combinations, stc ``knows'' what kind of argument is required and reports errors if these are incorrect. This may seem to make the implementation ``impure'' with respect to object orientation, but usually helps the programmer by flagging errors earlier (these will lead to a runtime error later, anyway).

Some of these checks can be turned of by stc command line arguments, which will force it to generate code even for suspect constructs.

limitations

Stc warning messagess

There are a few more (less frequent) error and warning messages which can be generated by the compiler. All of them should be self explanatory.

Diagnostics produced by the runtime system

In case of a severe error, the runtime system (also called VM) sends diagnostic to the standard errror (i.e. your shell terminal). Also informational messages are occasionally output, for example, garbage collection statistics.

Normally, you would not care for these messages, except if ST/X's output is piped to another program. In this case, you may want to suppress these messages.
(future versions will allow these to be written into a logfile as option)

Most debug & error messages can be suppressed by evaluating:

	Smalltalk debugPrinting:false
for the error messages, and:
	Smalltalk infoPrinting:false
for the informal messages. You may place the above expressions into any of your startup files, or evaluate them at any time in a workspace.

Alternatively, you can give additional command line arguments which suppress these messages right from the start:

	smalltalk -noDebugPrint -noInfoPrint
Finally, these can be enabled/disabled in the launchers settings-messages menu.

Messages for very severe errors (crashes) cannot be suppressed.

Starting with ST/X release 3, all system messages are prefixed by a subsystem name (such as "IRQ" or "MEM"), which specifies the part within the VM, where the message was generated, and a severity indicator (one of "error", "warning" or "info").
The subsystems are:

IRQ
the interrupt subsystem which handles the timer, user interrupts (CTRL-C), I/O interrupts and memory access violations.
MEM
memory management
IGC
incremental garbage collector (within the memory system)
GC
blocking (mark & sweep) garbage collector (within the memory system)
CGC
compressing garbage collector (within the memory system)
IMG
snapshot image save & reload subsystem
VM
other message
By convention, messages generated by Smalltalk code also follow the above convention, but print the name of the class which generated the message.
(This helps in searching for the origin of that message in the browser.)

Startup messages

Message lookup errors

Memory management errors

Memory management diagnostics

Other VM errors

Incremental compiler messages & popups

Misc information messages from various classes

In general, these messages do not report fatal conditions, but give useful background information on what is going on at a higher (smalltalk-) level.

These messages can be suppressed with:

Object infoPrinting:false
or via the launchers settings-messages menu.

Runtime errors (exceptions)

Most runtime errors raise a signal, which can be cought or handled in an exception handler. See the documentation on exceptions and/or read and understand the sample code in "doc/coding/Signal-xxx" for how this is done.

The following table lists (most) signals, where they are defined, and in which situation they are typically raised.
The list below may not be complete - there are still error situations in which only a general error is reported (instead of a specific signal). Most programmers are not affected by this, however, there may be situations where a single specific error has to be handled. In practice, these situations are rare and for most applications it is suffucient to handle the parent (Object>>ErrorSignal) in one handler.

For a complete (up-to-date) list, a browser on the "Signal constants" method category.
Notice, that you can handle all related child signals in one handler, by catching the common parent signal. For example, Object>>errorSignal is the common parent of all other signals - handling this one will also handle all others.

List of signals raised on errors

  signal                        in class        raised if

ErrorSignal Object any error not listed below. Also raised by the #error: method. This is the parent of all others. HaltSignal Object raised by the #halt method . MessageNotUnderStoodSignal Object no method for selector in a send. raised by the #doesNotUnderstand: method. UserInterruptSignal Object Ctrl-C was pressed RecursionInterruptSignal Object too much recursion (stack limit reached) A handler can increase the stack limit and continue execution. The stack limit can be changed by the program or via command line arguments. ExceptionInterruptSignal Object graphic display error. This is raised as a consequence of X Error reports. SubscriptOutOfBoundsSignal Object a subscript is not within 1..size (for example in an indexed array access) NonIntegerIndexSignal Object subscript is not integer (for example in an indexed array access) NotFoundSignal Object an element was not found in a collection KeyNotFoundSignal Object a key was not found in a collection ElementOutOfBoundsSignal Object element is not appropriate for collection (for example when storing non-characters into a string) DeepCopyErrorSignal Object invalid request for deepCopy * InformationSignal Object if handled, this is raised by the #information: method passing the info string. Allows info-boxes to be suppressed. * WarningSignal Object if handled, this is raised by the #warn: method passing the info string. Allows info-boxes to be suppressed. UserNotificationSignal Object parent of InformationSignal and WarningSignal. Allows info- and warnboxes to be suppressed by a common handler. * ActivityNotificationSignal Object request to display information about activity (to be displayed in a topViews title or info area) PrimitiveFailureSignal Object error in primitive code. The reason for raising this signal vary with the method; typically, this occurs when invalid arguments are passed to primitive code. * AbortSignal Object abort from debugger. This signal is special in that it is not raised for error conditions, but to leave some action and return to a save place. All views handle this signal in their event dispatching loop. OSSignals Object raised on unix-signal. To have a unix signal be reported as a smalltalk signal, the unix signal has to be first enabled, and then be bound to a signal object. InvalidKeySignal Collection access with invalid key. Typically, this is raised if nil is used as key in a set or dictionary. EmptyCollectionSignal Collection remove from an empty collection NotEnoughElementsSignal Collection too small of a collection ValueNotFoundSignal Collection a value was not found ColorAllocationFailSignal Color color allocation failed (while allocation fix colors) * CurrentScreenQuerySignal Display query for the current screen DeviceErrorSignal Display any display error TerminationSignal Process for soft termination of a process. Programs may handle this for cleanup (or to disallow termination) ExecutionErrorSignal Code parent of all execution errors PrivateMethodSignal Method tried to execute a private method InvalidCodeSignal Method/Block any execution error not below Also the parent of those. NoByteCodeSignal Method/Block bytecode is nil. InvalidByteCodeSignal Method/Block bytecode is not a ByteArray InvalidInstructionSignal Method/Block invalid instruction in bytecode BadLiteralsSignal Method/Block literal array is not an Array NonBooleanReceiverSignal Method/Block receiver of ifTrue/ifFalse is not a boolean ArgumentSignal Method/Block something wrong with argument(s). Raised if a blocks number of actual arguments does not match the number of formal arguments. Or, if a methids number of arguments is wrong in a #perform; or if the argument of a #performWithArgs: is not an array. CompilationFailedSignal LazyMethod a method could not be compiled when first executed InvalidReturnSignal Context return from a context which has already returned. ArithmeticSignal ArithmeticValue not directly raised. parent of all below. DivisionByZeroSignal ArithmeticValue a division by zero was attempted DomainErrorSignal ArithmeticValue value is out of domain for math-function (mainly with Floats) OverflowSignal ArithmeticValue overflow in arithmetic operation (mainly with Floats; not supported on all platforms) UnderflowSignal ArithmeticValue underflow in arithmetic operation (mainly with Floats; not supported on all platforms) AllocationFailureSignal ObjectMemory memory allocation failed. This signal is raised when either an object creation request or some buffer request (i.e. malloc) failed. If a handler exists, and it continues execution, a nil value will be returned from the object creation request. BreakpointSignal MessageTracer breakpoint hit InvalidNewSignal Block attempt to create a block with #new StreamErrorSignal Stream any stream error (parent of the others) EndOfStreamSignal Stream i/o past the end attempted PositionErrorSignal Stream invalid position ReadErrorSignal Stream read eror WriteErrorSignal Stream write error BrokenPipeSignal PipeStream read from a pipe or socket with no one writing ErrorDuringFileInSignal PositionableStream an error occured while filing in code. InvalidModeSignal ExternalStream binary i/o in textmode or vice versa InvalidOperationSignal ExternalStream an unsupported operation was attempted InvalidReadSignal ExternalStream reading is not supported InvalidWriteSignal ExternalStream writing is not supported OpenErrorSignal ExternalStream file/stream opening failed StreamNotOpenSignal ExternalStram i/o attempt with a closed stream * ImageNotFoundQuerySignal Image raised if a bitmap-image could not be loaded from a file. BreakpointSignal MessageTracer used for breakpointing FileOutErrorSignal Class an error occured while filing out code * CreateNameSpaceQuerySignal Class to ask if a new namespace should be created without user confirmation. (for example: during fileIn) MethodRedefinitionSignal Class raised, if an existing method is redefined in another package (if catchMethodRedefinition is enabled) * NameSpaceQuerySignal Class to ask for the nameSpace, into which new classes are to be installed. * PackageQuerySignal Class to ask for a package identifier for new classes and methods. * UpdateChangeFileQuerySignal Class to ask if the changeFile should be updated * UsedNameSpaceQuerySignal Class to ask for a collection of namespaces, from which names are to be resolved AutoloadFailedSignal Autoload a class could not be autoloaded AccessDeniedErrorSignal OperatingSystem access to some system resource was denied (no permission) FileNotFoundErrorSignal OperatingSystem some file was not found CompilationFailedSignal LazyMethod compilation of a lazy method failed NoHandlerSignal Signal an unhandled signal raise occured. If not handled by the application, this signal is always handled by a default handler, which opens a debugger on the failing process. RecursiveExceptionSignal Exception recursive signal raise in an exception handler. This is raised if the same exception occurs again in a signals exception handler, and no other handler for this exception was found. RestartSignal Process forces a process to restart TerminateSignal Process forces a process to (soft-) terminate BinaryLoadErrorSignal BinaryStorage parent of all binaryLoad errors. Also raised if a format error occurs. NonexistingClassSignal BinaryStorage attempt to load an object for which there is no class available. InvalidClassSignal BinaryStorage attempt to load an object for which there is no compatible class available Parent of below. ChangedInstLayoutSignal BinaryStorage the class has a different instance layout than the to be loaded objects class. (i.e. instance variables are not at the same position(s)) ChangedInstSizeSignal BinaryStorage the class has a different number of instance variables w.r.t. the loaded objects class. ChangedIndexedInstSignal BinaryStorage the class has indexed instance variables, while the loaded object has not; or vice versa. * RequestConversionSignal BinaryStorage raised to request a conversion of an incompatible object. * LastEventQuerySignal WindowGroup to ask for the last event LeaveSignal WindowGroup to ask for the eventLoop to be left * WindowGroupQuerySignal WindowGroup to ask for the current windowGroup (*) queries - no debugger/emergency if unhandled
*** this list may be incomplete, as newer systems may add more signals ***


Copyright © 1995 Claus Gittinger Development & Consulting

<cg@exept.de>

Doc $Revision: 1.28 $ $Date: 2009/09/21 13:52:21 $