Administrative Issues 

Error Handling Mechanism

The error handling mechanism must be done carefully in the logging tool. It must not disturb the running application. Therefore, the errors occurring within the logging framework have to be thrown and caught appropriately.

Workaround

The approach is to tolerate the exception and to correct the error. The program then continues to run. The exception is not lost; it is stored temporarily and can be retrieved by the caller through the getException() and throwException() methods.

Examples

Some of the potential mistakes are: invalid severity definition, poor configuration, meaningless null message string, wrong resource bundle information, and so on. These can be rectified internally and a message can be logged to indicate the problem without terminating the program. There are several ways of replacing the incorrect value with the best-guess value:

●      Using the default value.

More information: Appendix C: Default Behavior of Certain Objects.

●      Estimating the closest value.

●      Ignoring it.

For example:

■       Invalid configuration for FileLog for the pair of parameters limit and cnt. The default setting for FileLog is used, that is, limit and cnt are both equal to zero.

■       If a type error occurs when defining a Log or Formatter, the value is ignored and nothing is assigned.

■       A message string or message code must not be a null string. However, if this happens, a constant <null> is assigned.

■       When a message code cannot be resolved to a localized string, the value of the message code is used directly.

Exceptions generated from methods that are called in static field declarations and initializers lead to an immediate program termination when the class is loaded.