Okeydokey. Nick
On Jul 17, 2013, at 3:56 PM, Ralph Goers wrote: > I see your point. I guess we should leave ConfigurationException alone. > > Ralph > > > On Jul 17, 2013, at 1:03 PM, Nick Williams wrote: > >> The Javadoc for LoggingException says "Exception thrown when a exception >> occurs while logging." ConfigurationException is never thrown by logging, so >> extend LoggingException would change the meaning of LoggingException. Do we >> want to change the meaning of LoggingException to encompass all errors that >> could occur in Log4j? >> >> Nick >> >> On Jul 17, 2013, at 2:48 PM, Ralph Goers wrote: >> >>> 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] >>> >> >> >> --------------------------------------------------------------------- >> 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]
