I'm fine with having both AppenderRuntimeException and ConfigurationException extend LoggingException. I'm fine with renaming AppenderRuntimeException to AppenderLoggingException.
Ralph On Jul 17, 2013, at 12:21 PM, Nick Williams wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
