If you have used different software packages, you may have seen different message systems, which attempt to provide a coherent way of dealing with messages from the software, such as warnings, informational output, error messages, help text, and so on. In most cases, this is done through some variation of a dedicated message interface, such as the following, which is taken from STAF:

EML_MESSAGE("DUI:Initializing. ");
EML_MESSAGE("DUI:Starting. ");	

The idea is that you can, at the application level, decide what to do with certain types of messages. For example, you can switch warnings off completely, or send them to a different destination than informational messages, and so on. The C and C++ system itself provides you with "standard input" and "standard error"; the above approach takes this concept further to a larger number of different message categories.

This approach, however, has a number of problems.

• It forces you to route every message through the message handler or messages will still end up in the log files or on the screen, and can go unnoticed for a long time. It is the user (rather than the system) who must take special action to funnel the message through the message system.

• Also, once you adopt a given standard of message handling such as the one above, you are committed to providing the ``EML_'' libraries whereever the code is used. If you use more than one package, you may find that the message handlers are incompatible and take a lot of tweaking to get the job right.

• Also, in order to change the behavior of a message handler, you will typically need to relink your application with another library which implements the ``EML_'' library in the desired way.

• Finally, the interface to the ``EML_'' functions, having a fixed number of parameters, are not as flexible as the interfaces to cout, cerr, or printf. In practice you might be forced to output through sprintf to a string, which you then pass on to the message system. You would like the same flexibility (number of parameters, formatting) with the messaging system interfaces.

This message system which is used for PHENIX tries to eliminate the latter shortcomings.

• It intercepts all output generated by cout, cerr, and printf and forces it to be routed through the handler without explicit action by the user. There is no way a message can end up in the log files unintentionally.

• On the application level, it modifies the behavior of the standard cout, cerr, and printf methods. So this package will run fine in an unmodified environment without any special message handler in place.

• The behavior of the message handler is implemented in a (C++) class, so the behavior can be changed dynamically either by modifying the behavior of the object, or by replacing the handler object with a different one. In either way the behavior can be changed at run-time.

• Since the standard cout and printf interfaces are used, we retain the full formatting capability.