Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D2B218F.8020202@apache.org>
Date: Mon, 10 Jan 2011 16:11:11 +0100
From: Felix Knecht <felixk@apache.org>
Reply-To: felixk@apache.org
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Exception handling
References: <4D2B17E6.2080502@gmail.com>
In-Reply-To: <4D2B17E6.2080502@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> 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.
What about having a dedicated log file only for errors? Like this the 
common log file would still be readable.

>
> Right now, I think that I would rather have those stackTraces instead of
> spending hours debugging the server or adding some temporary
> e.printStackTraces in some random places. Typically, today, I tracked
> down a NPE which was generated by a error message using a null reference
> to inform the client about the cause of the error. Isn't it ironical
> that trying to give back some info when some error occurred you get a
> NPE ? No. In fact, it happens all the time, but we aren't protected
> against such mistakes.
>
> Now, I would suggest we add some handling of such exception at the
> higher level, ie in core-session.

+1

Overall it would be helpfull if we can still get the causing error and 
it's location even when mapping and/or swallowing errors for various 
reasons. Java5 can be helpfull as Exception can more and more be used in 
a cascading way.