Error_Reporting

Alternative Error Reporting

During the initialization phase or during the parsing phase an error can occur. While errors encountered during the initialization phase are most likely to be developer's typos and so are subject to correction between two builds, the parsing phase can encounter various exceptional conditions during the runtime as a result of user mistakes.
The Config class uses a simple plug-in mechanism for error reporting, which does not require any user intervention unless a specific change to the error reporting is required. The Config class declares a simple ErrorHandler interface. Instances of classes implementing the mentioned interface can be supplied to the Config parser instead of its default built-in implementation. This way one can achieve a completely different error handling behavior. The interface contains three methods: warning(), error and fatal(), which do the work; their description with the specification of the default built-in implementation follows.

ErrorHandler.warning(String message)

The warning() method is used to emit a warning message. Implementations must not abort the processing upon call to their warning() method. This method is required to throw no exceptions at all. The default implementation outputs the message prefixed with string "WARNING:" to the standard error.

ErrorHandler.error(String message)

The error() method serves for reporting of a significant error condition. The application can decide whether the condition is severe enough to abort the processing, or whether to take error-recovery measures and continue. The default implementation emits the message to standard error prefixed with the string "ERROR:" and resumes processing.

ErrorHandler.fatal(String message)

The method fatal() is called when an unrecoverable error condition has been met. Upon call to this method the implementation is required to abort the processing, but it is free to decide whether to shut down gracefully or forcefully. The default implementation throws a RuntimeException with message set to the message string prefixed with "FATAL:".

One can change the ErrorHandler either by calling the two-argument constructor or by using the

Config.setHandler(ErrorHandler eh)

method. Using the former approach results in having a Config parser that routes even the initialization phase errors through the supplied ErrorHandler, while the later approach routes only the parsing phase messages through the alternative ErrorHandler. It is obvious that the former approach is useful in applications that configure the parser dynamically and thus need to unify the error reporting throughout all the phases, while the later approach using the setHandler() method is suitable for applications that initialize the parser statically, which is probably the most frequent use of the CmdConfig library.