REFERENCE:


DEBUGGING:

DEBUGGING EIFFEL CODE
~~~~~~~~~~~~~~~~~~~~~

Eiffel: The Language describes a number of debugging options that are
supported in Eon/Eiffel. The following are implementation notes that
should be read in conjunction to the book.

Assertions. 

Assertions control is via the system description file ELACE. At
runtime, finer control can be achieved via the EON_ASSERT environment
variable. If this variable is not defined, all the assertions that
were compiled into the code will be checked and acted up if required.

EON_ASSERT may be set to one of or a combination of the following:

e	-	ensure
r	-	require
i	-	invariant
c	- 	check
l	-	loop
a	-	all
n	-	none

In the presense of EON_ASSERT only the specified conditions will be
checked. This applies to the whole system.

Example:

EON_ASSERT=erc

Here, only the pre and post conditions ("ensure" and "require") and "check"
statements are acted upon. The must, of course, have been specified in the
ELACE file.


When an assertion traps an error, a message will be generated
and the program aborted.

Example:
--------------------------------------------------------------
"ARRAY.put": Precondition failed
"inside_bounds" AND_THEN ( (lower <= index), (index <= upper))
No Traceback available.
--------------------------------------------------------------


If the program was compiled with the trace feature enabled, a traceback
will be displayed:

--------------------------------------------------------------
"ARRAY.put": Precondition failed
"inside_bounds" AND_THEN ( (lower <= index), (index <= upper))
Object     Class        Routine           Arguments
--------------------------------------------------------------
0x004076f0 ARRAY        put               element="a string"
                                          index="100"
==============================================================
--------------------------------------------------------------

This shows a condition in which an array element that is outside the 
arrays limits has been written too. The traceback shows the class, 
feature and parameters of the call in which the error was trapped.

The traceback is, for the most part, obvious. However the display of the
functions arguments require further examination because they show a data 
element for each class. 

In the example, index=100 clearly indicates the index
element to be 100 which is of type INTEGER. The first option, 
element="a string" is (if we look at the code) of type ANY. This raises
the question of how the traceback selects a text string from the 
supplied class.

The class GENERAL defines a function called `out'. This returns a 
string initialised to "out - not implemented". In order to make the
traceback arguments useful, a class must redefine `out' and make it
return a string that is relevent to that class. For example FILE would
return the name of the file that is open. STRING would (of course) return
whatever the current object is being used for.



Trace: If the trace option has been enabled, information for a traceback
listing is accumulated. In addition a log of functions and procedures
is maintained as the they are entered and exited. By setting the
EON_TRACE environment variable, a trace is displayed at the start and
end of a procedure or function:

Example:

-------------------------------------
+++ ARRAY.make
   +++ ARRAY.resize
      +++ ARRAY.initialise
      --- ARRAY.initialise
   --- ARRAY.resize
--- ARRAY.make
-------------------------------------

The "+++" symbol indicates that the named function has been entered. The
"---" symbol indicates the exit point.

The environment variable EON_TRACE does not require a value, it's existance
is tested for.

setenv EON_TRACE				Unix C shell

set EON_TRACE ; export EON_TRACE	Unix Bourne shell

set EON_TRACE=1				MSDOS


Runtime checking of null entities.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Under normal circumstancies an attempt to access a reference object 
that has not been created will end in disastor. On Unix a segmentation
violation will occur and on DOS anything could happen.

Example

	--------------------------
	str:STRING

	str := "DISASTER"
	--------------------------

The correct code, is more like:

	--------------------------
	str:STRING

	!!str.make
	str := "DISASTER"
	--------------------------

To prevent this unfriendly behavour, the compiler inserts code to
abort the program in a more informative way. If possible a traceback
is given along with a description of the class being abused.

This adds a small runtime overhead however the code can be removed
with the optimisation feature.


Runtime checking of polymorphic arrays
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If an array is of type ANY the runtime system will
track the type of the object refered to by each element of the array.

This is desirable because any error when assigning the array element 
to an entity of a different type will cause the program to either
crash or give unpredictable results.

Example:


	



