I think I see something subtle in what you are saying. If your JDBCDatabaseManager can't connect it shouldn't just fail forever. It should be capable of performing retries. Thus, the error might occur when logging an event and then it might establish a new connection for a subsequent event. So calling it AppenderLoggingException seems perfectly fine to me.
Ralph On Jul 17, 2013, at 12:18 PM, Ralph Goers wrote: > 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]
