Access to internal properties
In some applications, you may need to fine-tune the exception handling and memory management mechanisms. You may also need a simple way to access command-line arguments. In less common cases, you may require low-level access to internal properties of objects.
Class EXCEPTIONS enables you to control the handling of exceptions. UNIX_SIGNALS , discussed next, complements it for the special case of fine-grain signal handling on Unix or Unix-like platforms. Both are meant to be inherited by any class that needs their facilities.
The basic exception mechanism treats all exceptions in the same way. In some cases, it may be useful to discriminate in a Rescue clause between the various possible causes.
Class EXCEPTIONS provides the features to do this. Each kind of exception has an integer code, which you can use through several features:
- The integer-valued query exception which gives the code of the latest exception.
- Queries which determine the general nature of the latest exception:
is_signalwhich determines whether the exception was an operating system signal; is_developer_exceptionwhich determines whether it was explicitly caused by a raise, as explained next; assertion_violation.
recipient_namewhich gives the name of the exception's recipient - the routine that was interrupted by the exception.
The class also provides a set of constant integer-valued attributes which denote the various possible codes, such as
Another occasional requirement is for a mechanism to trigger an exception explicitly. Procedure raise answers this needs; the argument, a string, is the tag chosen for the exception. The code in this case is
You will notice in the interface specification for EXCEPTIONS that for some properties of the latest exception there are two features, one with a name such as exception or recipient_name as seen above and the other with a name prefixed by original_:
As you will see from the header comments in the flat-short form of class EXCEPTIONS , the queries that return detailed information about an exception, such as
The features of class EXCEPTIONS enable you to determine whether a certain exception is a signal - an operating system event such as may result from a child process that disappears, a window that is resized, a user that hits the Break key and many others. But they do not give you more details because the exact set of possible signals is highly platform-dependent.
Class UNIX_SIGNALS complements EXCEP_CONST by providing codes for the signals of Unix and similar systems, such as Sigkill for the 'kill' signal and Sigbus for bus error.
some_signal is an integer code, will determine whether some_signal is supported on the platform.
A class whose routines need to perform specific processing depending on the nature of signals received should inherit from UNIX_SIGNALS , or a similar class for another platform.
Because signal codes are platform-dependent, the features of UNIX_SIGNALS are implemented as once functions - computed on the first call - rather than constants, although this makes no difference to clients.
Class MEMORY , like EXCEPTIONS , is meant to be used as an ancestor by classes that need its facilities. It offers a number of features for controlling memory management and fine-tuning the garbage collection mechanism, a key component of the Eiffel Software environment.
One of the most useful features in this class is
Other features of MEMORY provide direct control over the operation of the garbage collector. You can in particular stop garbage collection through a call to
MEM_INFO, the result type for query
Writing, assembling and compiling a system yields an executable command. The system's users will call that command with arguments. These are normally provided in textual form on the command line, as in
your_system arg1 arg2 arg3
although one may conceive of other ways of entering the command arguments, such as tabular or graphical form-filling. In any case, the software must be able to access the values passed as command arguments.
A language mechanism is available for that purpose: the Root Class rule indicates that the creation procedure of the root class may have a single argument (in the Eiffel sense of argument to a routine) of type
ARRAY [STRING]. The corresponding array of strings will be initialized at the beginning of the system's execution with the values entered as arguments to that execution of the command.
Although this facility suffices in many cases, it is not always convenient if you suddenly need to access the command arguments in a class that is far away from the root. An alternative mechanism, class ARGUMENTS, is available. Once again, this is a class from which you should inherit if you need its facilities. It has just two exported features:
argument_count, a non-negative integer, is the number of command arguments.
), a string, is the i-th command argument. Here
imust be between 0 and
argument_count; the convention is that for
= 0the result is the name of the command itself.