On Wed, Jul 17, 2013 at 2:52 PM, Nick Williams <
[email protected]> 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?
>

Throwing a RuntimeException is an anti-pattern IMO.

At worse an IllegalStateException or IllegalArgumenException, unless a
log4j Exception is a better fit.

Gary


> 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]
>
>


-- 
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Reply via email to