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]
