So what about my proposal for renaming and changing inheritance of appender exception. Thoughts?
Nick On Jul 17, 2013, at 2: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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
