[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
whereas 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




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.


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 launcher's 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:

the interrupt subsystem which handles the timer, user interrupts (CTRL-C), I/O interrupts and memory access violations.
memory management
incremental garbage collector (within the memory system)
blocking (mark & sweep) garbage collector (within the memory system)
compressing garbage collector (within the memory system)
snapshot image save & reload subsystem
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 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 launcher's settings-messages menu.

Misc messages from non-Smalltalk library code

Smalltalk/X uses additional libraries and frameworks, which are typically written in C or C++. Also, some operations are implemented by calling out to external programs. These may generate additional information messages, which are not under control of ST/X (and thus cannot be easily suppressed).

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.

For a complete (up-to-date) list, a browser on the "Signal constants" method category
and on the "Exception hierarchy".
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.

Copyright © 1995 Claus Gittinger Development & Consulting


Doc $Revision: 1.36 $ $Date: 2018/05/08 17:39:50 $