directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Exception handling
Date Mon, 10 Jan 2011 17:05:03 GMT
On 1/10/11 4:11 PM, Felix Knecht wrote:
>> Since I started to work on the server almost 6 years ago, I was
>> convinced that writing StackTraces in the logs was a error, as it could
>> fill the logs very quickly, and make them grow so fast that any valuable
>> message could be buried into millions of lines of stack trace.
> If errors are swallowed or converted into other Exceptions it's always 
> not easy to trigger the real error cause. That's why I get used to log 
> an error when catching it - even when throwing afterwards a 
> transformed error.
I also do that. The closest to the origin, the better.

> What about having a dedicated log file only for errors? Like this the 
> common log file would still be readable.
This is something worth discussing. In many projects I was working on 
previously, I was used to define more than one logger :
- one generic logger for debugging purpose,
- one dedicated logger for things like DB connections, LDAP connection, 
Network connection, EJB cration/removal

I do think that dedicated loggers can help, and are easier to manipulate 
by an admin.

Currently, what we have in the server is a set of loggers based on the 
class name. It's really difficult to know which logger to filter when 
you only want to have information about, say, the ASN.1 layer.

I think having something like what OpenLDAP has - ie, multi-level 
loggers, depending on which aspect of the server you are interested in - 
is probably a must have.

One idea would also to be able to activate logs dynamically : changing 
the log level, or the logger to use, by modifying the configuration, 
would be great. As the configuration is now stored in the DIT, this is 
an approach we could use (another way would be to use JMX, but here, 
frankly, that would be overkilling and not persistent).

These ideas worth being discussed, that's for sure.


Emmanuel L├ęcharny

View raw message