Alexander, >What is wrong with get/serErrorManager for Formatter? It should be just >a way for Formatter to report its internal errors.
1. You can't inherit the Handler error manager until after construction of the formatter. That means the concept of inheriting an error manager from a handler is flawed. Forcing subclasses to include an ErrorManager or Handler constructor is not very clean either. Especially if the formatter already has constructors that take multiple arguments. 2. Formatters can decorate other formatters. See point #1. Logging does not allow for creating an ErrorManager that is hostile that allows an exception to escape (without resorting to hacks). Making the internal and external formatter work as one unit gets messy. 3. How do you control System.err chatter? It used to be that every handler had an error manager and every error manager could report one problem. If we increase the number of error managers we can increase the amount of chatter. 3. The JDK Handlers already expect that formatters throw exceptions see (StreamHandler). Publishing is where things are expected to fail. Everything that happens upstream from a Handler is expected not to fail. It is already cleanly established that the handler should be the mediator between the formatter and the error manager. The creation of a handler creates the error manager and formatters so it is much cleaner to have the formatter simply throw exceptions to the handler and have the handler delegate to the error manager. 4. ErrorManagers installed on formatters would mainly deal with programing bugs (pattern syntax errors and broken Object.toString implementations) not expected failures like I/O. Seems excessive to add an ErrorManager that conditionally handles bugs. Handers on the other hand can fail with checked exceptions like I/O which is a different class of errors. 5. ErrorManager properties on a Formatter is more API complexity and more mutable state to deal with and test. I think API producers and API consumers would like to avoid this debt. 6. ErrorManager defines an error code as an argument. If objects belonging to a Handler were supposed to have an ErrorManager we wouldn't need the code argument. This new addtion conflicts with the original design. 7. It is wasted object. Not all Handlers have just one formatter and those formatters can contain formatters. There are two clean ways errors should be reported in a formatter without changing the API. Either throw the exception to the caller (Handler) or format the error using a best effort and return it as a string. Going back to https://bugs.openjdk.java.net/browse/JDK-8028233, the pain point is that the error is lost when we create buggy Object.toString implementations. A very clean solution would be to make the formatter simply format the exception, the pattern syntax (record.getMessage), the types of the arguments (avoids calling overridden toString methods) and return a concatinated string. This gets around the limitation of reporting only one failure and is not hostile which is nice for compatiblity. Since we are dealing with formatMessage, changing the behavior doesn't break XMLFormatter or SimpleFormatter because that returned string is free form. All the API says is "returns a localized and formatted message" when faced with a bad command (pattern syntax error) it would be legal to alter the string returned in the failure case. Jason
