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.
> Th
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
>> occur
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 L
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
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 i
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,
I think I see something subtle in what you are saying. If your
JDBCDatabaseManager can't connect it shouldn't just fail forever. It should be
capable of performing retries. Thus, the error might occur when logging an
event and then it might establish a new connection for a subsequent event. S
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
> Loggin
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
JDBCDataba
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 shoul
Based on the name, I would hope that ConfigurationException is only thrown
when a problem is found reading and processing a config file. I've not
looked at this area of Log4j though
Gary
On Wed, Jul 17, 2013 at 2:23 PM, Nick Williams <
[email protected]> wrote:
> I'm working on
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
12 matches
Mail list logo
