Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-23 Thread Henning P. Schmiedehausen
Oliver Heger [EMAIL PROTECTED] writes: In this case I agree with Brett. An uncought exception will be no problem in a unit test. The fact that junit distinguishes between failures and errors should especially direct the developer's attention to that problem. It's okay with me. I was just

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Henning P. Schmiedehausen
[EMAIL PROTECTED] writes: public int hashCode() { -return keyBuffer.hashCode(); +return keyBuffer.toString().hashCode(); } This screams NullPointerException all over the place. How about public int hashCode() { return String.valueOf(keyBuffer).hashCode();

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Henning P. Schmiedehausen
[EMAIL PROTECTED] writes: +try +{ +it.next(); +fail(Could iterate over the iteration's end!); +} +catch(NoSuchElementException nex) +{ +//ok +} This allows it.next() to throw another exception which leads to an

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Brett Porter
How? if keyBuffer is null (which it isn't, the constructor initialises it), String.valueOf( keyBuffer ) would be an NPE as well. toString() should not return null and won't for a StringBuffer. - Brett Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] writes: public int hashCode()

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Brett Porter
I'm a little lost on this criticism also... a test that doesn't catch an uncaught exception will error out. An error with a trace would be more obvious to me than the assertEquals below, and much easier to read. Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] writes: +try +

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Henning P. Schmiedehausen
Brett Porter [EMAIL PROTECTED] writes: How? if keyBuffer is null (which it isn't, the constructor initialises it), String.valueOf( keyBuffer ) would be an NPE as well. toString() should not return null and won't for a StringBuffer. What the...? --- cut import java.io.File; public

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread sebb
On 22/08/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Brett Porter [EMAIL PROTECTED] writes: How? if keyBuffer is null (which it isn't, the constructor initialises it), String.valueOf( keyBuffer ) would be an NPE as well. toString() should not return null and won't for a

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Oliver Heger
Henning P. Schmiedehausen wrote: Brett Porter [EMAIL PROTECTED] writes: How? if keyBuffer is null (which it isn't, the constructor initialises it), String.valueOf( keyBuffer ) would be an NPE as well. toString() should not return null and won't for a StringBuffer. What

Re: svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src:

2005-08-22 Thread Oliver Heger
In this case I agree with Brett. An uncought exception will be no problem in a unit test. The fact that junit distinguishes between failures and errors should especially direct the developer's attention to that problem. Oliver Brett Porter wrote: I'm a little lost on this criticism also...

svn commit: r233505 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/ConfigurationKey.java test/org/apache/commons/configuration/TestConfigurationKey.java

2005-08-19 Thread oheger
Author: oheger Date: Fri Aug 19 09:16:31 2005 New Revision: 233505 URL: http://svn.apache.org/viewcvs?rev=233505view=rev Log: Minor fixes and increased unit test coverage Modified: jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationKey.java