I'd throw the appender exception since the database manager is acting as part of the Appender.
Ralph On Jul 17, 2013, at 11:52 AM, Nick Williams wrote: > Okay, so, proposal: I rename AppenderRuntimeException to > AppenderLoggingException and change it to extend LoggingException. Like > LoggingException, it should only be thrown when logging an event fails. > Thoughts? > > That still leaves the question of which exception I should throw when my > JDBCDatabaseManager can't connect. Perhaps just a RuntimeException for this > one-off scenario? > > Nick > > On Jul 17, 2013, at 1:43 PM, Ralph Goers wrote: > >> Perhaps AppenderRuntimeException should have extended LoggingException. As >> you might expect, AppenderRuntimeException is primarily for Appenders to >> throw as they need to. LoggingExceptions are thrown everywhere else. It is >> likely that LoggingException is being used in Appenders but those should be >> changed. >> >> As for ConfigurationException, my first instinct was that it would be for >> configuration errors, but it is only being used by the AsyncAppender and >> FlumeAppender. However, it is being thrown when it detects that those >> appenders were misconfigured so at least it makes sense from that standpoint. >> >> Ralph >> >> On Jul 17, 2013, at 11:23 AM, Nick Williams wrote: >> >>> I'm working on better exception handling in the DB appenders, and then I'll >>> see if other appenders are using best practices, too. >>> >>> Log4j 2 defines three different exceptions: LoggingException in the API and >>> AppenderRuntimeException and ConfigurationException in Core. >>> >>> I've pretty much figured out that my appenders, if they must wrap a checked >>> exception thrown by the storage mechanism _when logging an event_, should >>> use LoggingException (since it's the only one in the API). >>> >>> But I'm unclear on the purpose of AppenderRuntimeException vs >>> ConfigurationException. What is AppenderRuntimeException even for? Neither >>> of these exceptions have any Javadoc (which I intend to fix once we all >>> agree what their purpose is). A couple of appenders are using >>> AppenderRuntimeException instead of LoggingException in the append() method >>> (which doesn't seem right to me). >>> >>> My particular use case is that my JDBCDatabaseManager's connectInternal and >>> disconnectInternal methods execute code that throws SQLException. I need to >>> catch this SQLException and wrap it in an unchecked exception. Not sure >>> whether a ConfigurationException (since a failure to connect is likely >>> related to configuration) or an AppenderRuntimeException should be used >>> here. >>> >>> Thoughts? >>> >>> Nick >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
