Administrative Issues 

Error Handling Mechanism

The error handling mechanism must be done carefully in the logging tool. That is, 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.

In addition, use the logging framework to log the exception message to the internal dedicated category System/Logging (normally, with severity ERROR and with an output to the console). In this way, you can monitor the reason for certain behavior while the application is running. This is very robust for runtime exceptions, such as java.lang.IllegalArgumentException, java.lang.NullPointerException, and so on.

Example

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, estimating the closest value, or simply ignoring it. For example:

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

●      For some reasons, if the severity level has been out of the range of the defined Severity.MAX and Severity.MIN, the severity will be corrected to the closest limit (MINor MAX).

●      If you make a spelling mistake 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.