An important feature of the Logging API is that the logging methods called by applications never throw exceptions: it is not reasonable to expect programmers to nest all their logging calls within try/catch blocks, and even if they did, there is no useful way for an application to recover from an exception in the logging subsystem. Since handler classes such as FileHandler are inherently subject to I/O exceptions, the ErrorManager provides a way for a handler to report an exception instead of simply discarding it. All Handler objects have an instance of ErrorManager associated with them. If an exception occurs in the handler, it passes the exception, along with a message and one of the error code constants defined by ErrorManager to the error( ) method. error( ) writes a message describing the exception to System.err , but does so only the first time it is called: the expectation is that a Handler that throws an exception once will continue to throw the same exception with each subsequent log message, and it is not useful to flood System.err with repeated error messages. You can of course define subclasses of ErrorManager that override error( ) to provide some other reporting mechanism. If you do this, register an instance of your custom ErrorManager by calling the setErrorManager( ) method of your Handler . public class ErrorManager { // Public Constructors public ErrorManager ( ); // Public Constants public static final int CLOSE_FAILURE ; =3 public static final int FLUSH_FAILURE ; =2 public static final int FORMAT_FAILURE ; =5 public static final int GENERIC_FAILURE ; =0 public static final int OPEN_FAILURE ; =4 public static final int WRITE_FAILURE ; =1 // Public Instance Methods public void error (String msg , Exception ex , int code ); synchronized } Passed ToHandler.setErrorManager( ) Returned ByHandler.getErrorManager( ) |