You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by br...@apache.org on 2013/08/29 22:18:13 UTC
svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Author: britter
Date: Thu Aug 29 20:18:13 2013
New Revision: 1518802
URL: http://svn.apache.org/r1518802
Log:
Make methods that create parsers or printers fail early and provide an expressive error messages. Document new behavior in JavaDoc
Added:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java (with props)
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java (with props)
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java
commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
Added: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java?rev=1518802&view=auto
==============================================================================
--- commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java (added)
+++ commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java Thu Aug 29 20:18:13 2013
@@ -0,0 +1,19 @@
+package org.apache.commons.csv;
+
+/**
+ * Utility class for input parameter validation
+ *
+ * @version $Id$
+ */
+final class Assertions {
+
+ private Assertions() {
+ // can not be instantiated
+ }
+
+ public static <T> void notNull(T parameter, String parameterName) {
+ if (parameter == null) {
+ throw new IllegalArgumentException("Parameter '" + parameterName + "' must not be null!");
+ }
+ }
+}
Propchange: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java
------------------------------------------------------------------------------
svn:keywords = Id
Modified: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java?rev=1518802&r1=1518801&r2=1518802&view=diff
==============================================================================
--- commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java (original)
+++ commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java Thu Aug 29 20:18:13 2013
@@ -96,14 +96,19 @@ public final class CSVParser implements
* Creates a parser for the given {@link File}.
*
* @param file
- * a CSV file
+ * a CSV file. Must not be null.
* @param format
- * the CSVFormat used for CSV parsing
+ * the CSVFormat used for CSV parsing. Must not be null.
* @return a new parser
+ * @throws IllegalArgumentException
+ * If the parameters of the format are inconsistent or if either file or format are null.
* @throws IOException
* If an I/O error occurs
*/
public static CSVParser parse(File file, final CSVFormat format) throws IOException {
+ Assertions.notNull(file, "file");
+ Assertions.notNull(format, "format");
+
return new CSVParser(new FileReader(file), format);
}
@@ -111,14 +116,19 @@ public final class CSVParser implements
* Creates a parser for the given {@link String}.
*
* @param string
- * a CSV string
+ * a CSV string. Must not be null.
* @param format
- * the CSVFormat used for CSV parsing
+ * the CSVFormat used for CSV parsing. Must not be null.
* @return a new parser
+ * @throws IllegalArgumentException
+ * If the parameters of the format are inconsistent or if either string or format are null.
* @throws IOException
* If an I/O error occurs
*/
public static CSVParser parse(String string, final CSVFormat format) throws IOException {
+ Assertions.notNull(string, "string");
+ Assertions.notNull(format, "format");
+
return new CSVParser(new StringReader(string), format);
}
@@ -131,17 +141,22 @@ public final class CSVParser implements
* </p>
*
* @param url
- * a URL
+ * a URL. Must not be null.
* @param charset
* the charset for the resource, if {@code null}, uses {@code UTF-8}. UTF-8 is one of the encodings
* required by the Java specification.
* @param format
- * the CSVFormat used for CSV parsing
+ * the CSVFormat used for CSV parsing. Must not be null.
* @return a new parser
+ * @throws IllegalArgumentException
+ * If the parameters of the format are inconsistent or if either url or format are null.
* @throws IOException
* If an I/O error occurs
*/
public static CSVParser parse(URL url, Charset charset, final CSVFormat format) throws IOException {
+ Assertions.notNull(url, "url");
+ Assertions.notNull(format, "format");
+
return new CSVParser(new InputStreamReader(url.openStream(),
charset == null ? Charset.forName("UTF-8") : charset), format);
}
@@ -169,15 +184,18 @@ public final class CSVParser implements
* </p>
*
* @param reader
- * a Reader containing CSV-formatted input
+ * a Reader containing CSV-formatted input. Must not be null.
* @param format
- * the CSVFormat used for CSV parsing
+ * the CSVFormat used for CSV parsing. Must not be null.
* @throws IllegalArgumentException
- * thrown if the parameters of the format are inconsistent
+ * If the parameters of the format are inconsistent or if either reader or format are null.
* @throws IOException
* If an I/O error occurs
*/
public CSVParser(final Reader reader, final CSVFormat format) throws IOException {
+ Assertions.notNull(reader, "reader");
+ Assertions.notNull(format, "format");
+
format.validate();
this.format = format;
this.lexer = new Lexer(format, new ExtendedBufferedReader(reader));
Modified: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java?rev=1518802&r1=1518801&r2=1518802&view=diff
==============================================================================
--- commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java (original)
+++ commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java Thu Aug 29 20:18:13 2013
@@ -49,15 +49,18 @@ public final class CSVPrinter implements
* (encapsulation and escaping with a different character) are not supported.
*
* @param out
- * stream to which to print.
+ * stream to which to print. Must not be null.
* @param format
- * the CSV format. If null the default format is used ({@link CSVFormat#DEFAULT})
+ * the CSV format. Must not be null.
* @throws IllegalArgumentException
- * thrown if the parameters of the format are inconsistent
+ * thrown if the parameters of the format are inconsistent or if either out or format are null.
*/
public CSVPrinter(final Appendable out, final CSVFormat format) {
+ Assertions.notNull(out, "out");
+ Assertions.notNull(format, "format");
+
this.out = out;
- this.format = format == null ? CSVFormat.DEFAULT : format;
+ this.format = format;
this.format.validate();
}
Added: commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java?rev=1518802&view=auto
==============================================================================
--- commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java (added)
+++ commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java Thu Aug 29 20:18:13 2013
@@ -0,0 +1,19 @@
+package org.apache.commons.csv;
+
+import org.junit.Test;
+
+/**
+ * @version $Id$
+ */
+public class AssertionsTest {
+
+ @Test
+ public void testNotNull() throws Exception {
+ Assertions.notNull(new Object(), "object");
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testNotNullNull() throws Exception {
+ Assertions.notNull(null, "object");
+ }
+}
Propchange: commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java
------------------------------------------------------------------------------
svn:keywords = Id
Modified: commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java?rev=1518802&r1=1518801&r2=1518802&view=diff
==============================================================================
--- commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java (original)
+++ commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java Thu Aug 29 20:18:13 2013
@@ -28,10 +28,13 @@ import static org.junit.Assert.assertNul
import static org.junit.Assert.assertTrue;
import static org.junit.Assert.fail;
+import java.io.File;
import java.io.IOException;
import java.io.Reader;
import java.io.StringReader;
import java.io.StringWriter;
+import java.net.URL;
+import java.nio.charset.Charset;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
@@ -721,6 +724,46 @@ public class CSVParserTest {
new CSVParser(null, invalidFormat).close();
}
+ @Test(expected = IllegalArgumentException.class)
+ public void testParseNullFileFormat() throws Exception {
+ CSVParser.parse((File) null, CSVFormat.DEFAULT);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testParseFileNullFormat() throws Exception {
+ CSVParser.parse(new File(""), null);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testParseNullStringFormat() throws Exception {
+ CSVParser.parse((String) null, CSVFormat.DEFAULT);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testParseStringNullFormat() throws Exception {
+ CSVParser.parse("csv data", null);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testParseNullUrlCharsetFormat() throws Exception {
+ CSVParser.parse(null, Charset.defaultCharset(), CSVFormat.DEFAULT);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testParseUrlCharsetNullFormat() throws Exception {
+ CSVParser.parse(new URL("http://commons.apache.org"), Charset.defaultCharset(), null);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testNewCSVParserNullReaderFormat() throws Exception {
+ new CSVParser(null, CSVFormat.DEFAULT);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testNewCSVParserReaderNullFormat() throws Exception {
+ new CSVParser(new StringReader(""), null);
+ }
+
private void validateRecordNumbers(final String lineSeparator) throws IOException {
final CSVParser parser = CSVParser.parse("a" + lineSeparator + "b" + lineSeparator + "c", CSVFormat.DEFAULT.withRecordSeparator(lineSeparator));
CSVRecord record;
Modified: commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java?rev=1518802&r1=1518801&r2=1518802&view=diff
==============================================================================
--- commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java (original)
+++ commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java Thu Aug 29 20:18:13 2013
@@ -487,6 +487,16 @@ public class CSVPrinterTest {
@Test(expected = IllegalArgumentException.class)
public void testInvalidFormat() throws Exception {
final CSVFormat invalidFormat = CSVFormat.DEFAULT.withDelimiter(CR);
- new CSVPrinter(null, invalidFormat).close();
+ new CSVPrinter(new StringWriter(), invalidFormat).close();
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testNewCSVPrinterNullAppendableFormat() throws Exception {
+ new CSVPrinter(null, CSVFormat.DEFAULT);
+ }
+
+ @Test(expected = IllegalArgumentException.class)
+ public void testNewCsvPrinterAppendableNullFormat() throws Exception {
+ new CSVPrinter(new StringWriter(), null);
}
}
RE: svn commit: r1518802 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
In the Pivot project, we use IllegalArgumentException for null input
cases where we "fail early". Just FYI... Seems a bit easier for the
user to tell that the specified argument wasn't acceptable to the API.
~Roger
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Friday, August 30, 2013 7:31 AM
To: Commons Developers List
Subject: Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
> I've removed the generics in r1518974, thanks for spotting that sebb.
>
> Regarding the exception to throw I'm indifferent. The important thing
> is to fail early.
>
... and with a helpful message.
> I personally thing that NPE should be reserved for signaling that some
> code tried to invoke a method on a null reference.
+1
> In our case null is illegal because we know that some code later on
> would break if we accept a null reference. So IllegalStateException
makes sense.
s/IllegalStateException /IllegalArgumentException/
+1
> Imaging having a method that accepts an int and only positive ints are
> valid. You would throw an IllegalArgumentException if a negative int
> is passed to that method and not a NegativeIntegerException (or what
ever).
> But James has a point. If [LANG] uses NPE maybe we should stick to
this.
I don't think we have to do the same as LANG, so long as the Javadoc is
clear.
> Feel free to change it. I'll leave it for now since there doesn't seem
> to be consensus?!
Unless there are other reasons than "LANG happens to use NPE" I think we
should stick with IAE, as it more clearly indicates the the problem is
not within the method throwing it.
The problem with using NPE to flag parameter errors is that it confuses
the user as to the likely cause.
Leave NPEs to the runtime system.
> Benedikt
>
>
> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>
>> Well, the problem with using NPE is that we as Java developers have
>> learned through the years that NPE typically is an "oh crap"
>> situation, where something is terribly wrong (we hate seeing those).
>> Thus, our users may have knee-jerk reactions and not even know to
>> inspect the message for the real cause. IAE is less alarming, IMHO.
>> Just my $0.02, but we've been doing it that way for a long time in
>> [lang], so be it.
>>
>>
>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
>> > AFAIK "accidental" NPEs don't have a message associated with them.
>> >
>> > So provided that the assertion generates the NPE with a suitable
>> > message (e.g.as currently done for the IAE) then it *should* be
>> > possible for the end user to distinguish the two cases.
>> >
>> > I am slightly in favour of retaining IAE as the cause is obvious
>> > with needing to look at the NPE message.
>> >
>> > ==
>> >
>> > Horrible hack: - if you want to use NPE, you could wrap an IAE in
>> > the
>> NPE:
>> >
>> > npe = new NPE(msg);
>> > npe.initCause(new IAE(msg));
>> > throw npe;
>> >
>> > Or vice-vera, of course!
>> >
>> > Not sure that gains anything, but it does make the stack trace look
>> > more impressive!
>> >
>> > On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
>> wrote:
>> >> Commons Lang's Validate.notNull() throws NPEs. I don't know that
>> >> I've necessarily agreed with that, but at some point a decision
>> >> was made that null constraint violations should throw NPEs. Food
for thought.
>> >>
>> >> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory
>> >> <ga...@gmail.com>
>> wrote:
>> >>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg
>> >>> <eb...@apache.org>
>> wrote:
>> >>>
>> >>>>
>> >>>> >> + if (parameter == null) {
>> >>>> >> + throw new IllegalArgumentException("Parameter '"
>> >>>> >> + +
>> >>>> parameterName + "' must not be null!");
>> >>>> >> + }
>> >>>> >> + }
>> >>>> >> +}
>> >>>>
>> >>>> Isn't a null value supposed to throw a NPE ?
>> >>>>
>> >>>
>> >>> Not always IMO. When I see an NPE I assume something is very
>> >>> wrong and
>> that
>> >>> it could be a bug in the impl OR a call site, somewhere on the
>> >>> code
>> path.
>> >>>
>> >>> With an IAE, I know for sure it's a problem in the call site
>> >>> (which
>> could
>> >>> be a bug of course).
>> >>>
>> >>> I does not help that the JRE/JDK is inconsistent, so it's hard to
>> >>> find examples.
>> >>>
>> >>> Gary
>> >>>
>> >>>
>> >>>> Emmanuel Bourg
>> >>>>
>> >>>>
>> >>>> ----------------------------------------------------------------
>> >>>> ----- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 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
>> >>
>> >> ------------------------------------------------------------------
>> >> --- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> > -------------------------------------------------------------------
>> > -- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Phil Steitz <ph...@gmail.com>.
On 9/2/13 3:30 PM, James Carman wrote:
> I get both sides of the argument. I just know how I feel when I see
> an NPE. It's probably more of a psychological thing for me, I guess.
> I just prefer IAE in these cases.
I do as well. The key for me is Gary's point about activation site
- where exactly the exception is triggered. If it is detected at an
API boundary, then IAE makes sense to me. I like (where practical)
to document null handling in API documentation and if the
documentation says nulls are not allowed, throw IAE. I don't like
the "just let the runtime go boom" approach when I can avoid it. As
a user, I would much rather see an IAE where a (documented) null
check failed than an NPE bubbling up from the bowels of some impl
that I don't know anything about.
An analogous case that may not convince anyone is to consider
ArrayIndexOutOfBoundsException triggered when an API is given bad
array indices. There as well, I would see a) failfast better and b)
IAE thrown instead of AIOOBE.
All that said, we more or less agreed on a different approach for
[math] [1], so I understand above may be a minority view.
Phil
[1] http://markmail.org/message/cl2e6c4pqbluo63e
>
> On Mon, Sep 2, 2013 at 3:27 PM, Matt Benson <gu...@gmail.com> wrote:
>> To continue to play devil's advocate, when one validates that an argument
>> is not null, doesn't this signify that in the absence of such validation,
>> NPE is what would be thrown anyway? Arguably throwing NPE from
>> Validate#notNull() simply allows the API designer to explicitly address
>> this and optionally provide a more detailed exception message in the
>> process.
>>
>> Matt
>>
>>
>> On Mon, Sep 2, 2013 at 1:46 PM, James Carman <ja...@carmanconsulting.com>wrote:
>>
>>> I think Emmanuel Bourg was the only one actually advocating NPE (or
>>> asking if it's what should be used). I brought up the fact that
>>> [lang] uses NPE merely as a discussion point. I don't agree with the
>>> NPE usage for Validate.notNull() (sorry I was not more clear on that
>>> opinion). I would rather have all of Validate's methods throw IAE for
>>> consistency. As far as this case is concerned, the only thing you
>>> would have to worry about would be a veto from someone, and since
>>> Emmanuel was the only dissenting voice, perhaps he would want to weigh
>>> in at this point. Emmanuel?
>>>
>>> I don't know if I would agree that Bloch has "codified this
>>> expectation into the minds of developers." I've been developing in
>>> Java for a long time and when I see a NPE, I immediately think this
>>> results from an attempt to dereference a null reference. Judging from
>>> the discussion here, I would think others feel the same way.
>>>
>>> On Mon, Sep 2, 2013 at 1:49 PM, Benedikt Ritter <be...@gmail.com>
>>> wrote:
>>>> Hey,
>>>>
>>>> sorry if I missunderstood your opinions (Gary and James).
>>>> So do we call for a [VOTE]? I've never seen a vote thread for design
>>>> related decisions so far.
>>>>
>>>> Benedikt
>>>>
>>>>
>>>> 2013/9/2 James Carman <ja...@carmanconsulting.com>
>>>>
>>>>> I meant re-visit the decision to make sure we took everything into
>>>>> consideration when choosing which way to go in this case. I say we
>>>>> leave [lang] alone at this point.
>>>>>
>>>>>
>>>>> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gu...@gmail.com>
>>> wrote:
>>>>>> How do you mean, "revisit?" I think changing [lang] at this late date
>>>>> would
>>>>>> be more trouble than it's worth.
>>>>>>
>>>>>> Matt
>>>>>> On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com>
>>>>> wrote:
>>>>>>> I favor IAE, but I want to make sure we re-visit the decision made
>>> for
>>>>>>> [lang] when it chose to use NPE instead.
>>>>>>>
>>>>>>> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <garydgregory@gmail.com
>>>>>>> wrote:
>>>>>>>> It feels to me that this misrepresents the ideas expressed here,
>>> or at
>>>>>>>> least mine ;) I am neither indifferent or favor NPE. I favor IAE,
>>> so
>>>>>>>> does that mean I am nor "most people". If a person make these
>>> kinds of
>>>>>>>> statement, we might as well VOTE or argue-discuss some more...!
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org>
>>> wrote:
>>>>>>>>> Look's like most people are either indifferent or favor NPE. So,
>>> do
>>>>> we
>>>>>>>>> change this for [CSV]? The important thing is to give users an
>>>>>>> expressive
>>>>>>>>> message.
>>>>>>>>>
>>>>>>>>> Benedikt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/8/30 Gary Gregory <ga...@gmail.com>
>>>>>>>>>
>>>>>>>>>> Surprisingly, a lot. At work, we have a lot of
>>>>> frameworky/plugin-type
>>>>>>> of
>>>>>>>>>> code where we run operations on collections of things and we do
>>> not
>>>>>>> want
>>>>>>>>>> "expected" errors to torpedo the whole processing flow, so we do
>>>>> catch
>>>>>>>>>> things like IAE and ISE. We do try to avoid catching Exception
>>> if we
>>>>>>> can
>>>>>>>>>> help it.
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <
>>> gudnabrsam@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>> How often do you really want to catch these?
>>>>>>>>>>>
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>>>>> garydgregory@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> Another perspective to think about is whether you want to write
>>>>> code
>>>>>>>>>>> like:
>>>>>>>>>>>> try {
>>>>>>>>>>>> // la-di-da
>>>>>>>>>>>> } catch (NullPointerException e) {
>>>>>>>>>>>> // garbage in!
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> or:
>>>>>>>>>>>>
>>>>>>>>>>>> try {
>>>>>>>>>>>> // doo-wap-doo-wap
>>>>>>>>>>>> } catch (IllegalArugumentException e) {
>>>>>>>>>>>> // garbage in!
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Catching NPE just smells funny to me.
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com>
>>> wrote:
>>>>>>>>>>>>> The fact that NPE is documented in Bloch is quite important.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whatever we do choose, we should make sure to document all th
>>>>>>> reasons
>>>>>>>>>>>>> (pros and cons) somewhere other than just the mailing list!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>> The discussion for [lang], none of whose participants have
>>>>> weighed
>>>>>>>>>> in
>>>>>>>>>>>>> here,
>>>>>>>>>>>>>> took place in late 2009 (so perhaps a little longer ago than
>>> I
>>>>>>>>>>> thought)
>>>>>>>>>>>>> and
>>>>>>>>>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
>>>>>>>>>>> arguments
>>>>>>>>>>>>> in
>>>>>>>>>>>>>> [2].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
>>>>>>>>>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>>> The JDK Javadoc says of NPE:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Applications should throw instances of this class to
>>> indicate
>>>>>>>>>>>>>>> * other illegal uses of the <code>null</code> object.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and of IAE:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Thrown to indicate that a method has been passed an
>>> illegal
>>>>> or
>>>>>>>>>>>>>>> * inappropriate argument.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That says to me that we should throw IAE here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The JDK does use NPE for parameter checks, but it also uses
>>>>> IAE,
>>>>>>>>>> for
>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> javax.management.monitor.Monitor.addObservedObject
>>>>>>>>>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
>>>>>>>>>>>>>>> javax.management.relation.RoleList.add
>>>>>>>>>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 30 August 2013 16:50, Adrian Crum <
>>>>>>>>>>>>> adrian.crum@sandglass-software.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in
>>> the
>>>>> end
>>>>>>>>>>>> they
>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>> condense down to what Matt stated here: Those who favor NPE
>>>>> cite
>>>>>>>>>>> the
>>>>>>>>>>>>> JDK
>>>>>>>>>>>>>>>> classes as a pattern to follow, and those who favor IAE
>>> say it
>>>>>>>>>> is
>>>>>>>>>>> a
>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>> description of the problem. From my perspective, both are
>>>>> valid
>>>>>>>>>>>>>>> viewpoints,
>>>>>>>>>>>>>>>> and a project simply needs to choose one. In the end, the
>>>>> choice
>>>>>>>>>>> is
>>>>>>>>>>>>>>> neither
>>>>>>>>>>>>>>>> "right" nor "wrong" - it is just a choice.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
>>>>>>>>>>>>>>>>> Let me stir the pot:
>>>>>>>>>>>>>>>>> At a fundamental level I agree that a required
>>> *argument*
>>>>>>>>>>> should
>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>> IllegalArgumentException when null is supplied. However,
>>>>> ISTR
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> decision
>>>>>>>>>>>>>>>>> to do otherwise in [lang] having been discussed on-list in
>>>>> the
>>>>>>>>>>>>>>>>> not-so-distant past, and the result of that discussion
>>> being
>>>>>>>>>> that
>>>>>>>>>>>>> NPE is
>>>>>>>>>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
>>>>>>>>>>>>> characterize
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now,
>>>>> [lang]
>>>>>>>>>>> is
>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> slightly unique situation as its stated mission is to
>>>>>>>>>> complement
>>>>>>>>>>>> Java
>>>>>>>>>>>>>>> SE,
>>>>>>>>>>>>>>>>> so it could be argued that [lang] is under greater
>>> pressure
>>>>> to
>>>>>>>>>>>>> conform
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> that reason. But my personal preference, in light of the
>>>>>>>>>>> standing
>>>>>>>>>>>>>>>>> decision
>>>>>>>>>>>>>>>>> with [lang], would be for consistency throughout Commons
>>>>>>>>>>> components
>>>>>>>>>>>>>>>>> *despite* the fact that at a purely semantic level I agree
>>>>> with
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> arguments in favor of IllegalArgumentException.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To summarize, +1 for NullPointerException from me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
>>>>>>>>>>>> britter@apache.org
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
>>>>> britter@apache.org
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> I've removed the generics in r1518974, thanks for
>>> spotting
>>>>>>>>>>> that
>>>>>>>>>>>>> sebb.
>>>>>>>>>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
>>>>>>>>>>> important
>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> fail early.
>>>>>>>>>>>>>>>>>>> ... and with a helpful message.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I personally thing that NPE should be reserved for
>>>>> signaling
>>>>>>>>>>>> that
>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>> tried to invoke a method on a null reference.
>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In our case null is illegal because we know that some
>>> code
>>>>>>>>>>> later
>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>> break if we accept a null reference. So
>>>>>>>>>> IllegalStateException
>>>>>>>>>>>>> makes
>>>>>>>>>>>>>>>>>>> sense.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>> Sorry, I meant IAE of corse.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Imaging having a method that accepts an int and only
>>>>>>>>>> positive
>>>>>>>>>>>> ints
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
>>>>>>>>>>> negative
>>>>>>>>>>>>> int
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> passed to that method and not a
>>> NegativeIntegerException
>>>>> (or
>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>> ever).
>>>>>>>>>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we
>>> should
>>>>>>>>>>> stick
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>> I don't think we have to do the same as LANG, so long as
>>>>> the
>>>>>>>>>>>>> Javadoc
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> clear.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Feel free to change it. I'll leave it for now since
>>> there
>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> be consensus?!
>>>>>>>>>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
>>>>>>>>>> NPE" I
>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>> we should stick with IAE, as it more clearly indicates
>>> the
>>>>>>>>>> the
>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>>>>> is not within the method throwing it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The problem with using NPE to flag parameter errors is
>>> that
>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> confuses the user as to the likely cause.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Leave NPEs to the runtime system.
>>>>>>>>>>>>>>>>>> agreed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Benedikt
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
>>>>>>>>>>> developers
>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
>>>>>>>>>> crap"
>>>>>>>>>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
>>>>>>>>>> seeing
>>>>>>>>>>>>> those).
>>>>>>>>>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not
>>> even
>>>>>>>>>>> know
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
>>>>>>>>>>> alarming,
>>>>>>>>>>>>> IMHO.
>>>>>>>>>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a
>>>>> long
>>>>>>>>>>> time
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> [lang], so be it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <
>>> sebbaz@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message
>>> associated
>>>>>>>>>> with
>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>> So provided that the assertion generates the NPE
>>> with a
>>>>>>>>>>>> suitable
>>>>>>>>>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
>>>>>>>>>>> *should*
>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> possible for the end user to distinguish the two
>>> cases.
>>>>>>>>>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the
>>> cause is
>>>>>>>>>>>> obvious
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>> needing to look at the NPE message.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ==
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could
>>> wrap
>>>>> an
>>>>>>>>>>> IAE
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> NPE:
>>>>>>>>>>>>>>>>>>>>>> npe = new NPE(msg);
>>>>>>>>>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
>>>>>>>>>>>>>>>>>>>>>> throw npe;
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Or vice-vera, of course!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Not sure that gains anything, but it does make the
>>> stack
>>>>>>>>>>> trace
>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>>>>>>> more impressive!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
>>>>>>>>>>>>> james@carmanconsulting.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I
>>> don't
>>>>>>>>>>> know
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
>>>>>>>>>> decision
>>>>>>>>>>>> was
>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>>>>>>>>> that null constraint violations should throw NPEs.
>>>>> Food
>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> thought.
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>>>>>>>>>>>>>>>>>>> garydgregory@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>>>>>>>>>>>>>>>> ebourg@apache.org>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
>>>>>>>>>>>>>>>>>>>>>>>>>>> + throw new
>>>>>>>>>>>> IllegalArgumentException("Parameter
>>>>>>>>>>>>> '"
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
>>>>>>>>>>>>>>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>>>>>>>>>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume
>>> something
>>>>> is
>>>>>>>>>>> very
>>>>>>>>>>>>>>> wrong
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site,
>>>>> somewhere
>>>>>>>>>> on
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>> path.
>>>>>>>>>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the
>>>>> call
>>>>>>>>>>> site
>>>>>>>>>>>>>>>>>> (which
>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>>>> be a bug of course).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent,
>>> so
>>>>>>>>>> it's
>>>>>>>>>>>>> hard to
>>>>>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>>>>>>>>>>> examples.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Emmanuel Bourg
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com |
>>> ggregory@apache.org
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@commons.apache.org
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help@commons.apache.org
>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>>>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>>>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>>>>>>>>>>>> http://github.com/britter
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>>>>>>>>>> http://github.com/britter
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>> http://github.com/britter
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 02/09/2013 20:46, James Carman a écrit :
> Emmanuel was the only dissenting voice, perhaps he would want to weigh
> in at this point. Emmanuel?
I asked because I was under the impression that throwing a NPE in this
case was the most common practice. But I don't care much as long as the
exception message is explicit.
Emmanuel Bourg
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
I get both sides of the argument. I just know how I feel when I see
an NPE. It's probably more of a psychological thing for me, I guess.
I just prefer IAE in these cases.
On Mon, Sep 2, 2013 at 3:27 PM, Matt Benson <gu...@gmail.com> wrote:
> To continue to play devil's advocate, when one validates that an argument
> is not null, doesn't this signify that in the absence of such validation,
> NPE is what would be thrown anyway? Arguably throwing NPE from
> Validate#notNull() simply allows the API designer to explicitly address
> this and optionally provide a more detailed exception message in the
> process.
>
> Matt
>
>
> On Mon, Sep 2, 2013 at 1:46 PM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> I think Emmanuel Bourg was the only one actually advocating NPE (or
>> asking if it's what should be used). I brought up the fact that
>> [lang] uses NPE merely as a discussion point. I don't agree with the
>> NPE usage for Validate.notNull() (sorry I was not more clear on that
>> opinion). I would rather have all of Validate's methods throw IAE for
>> consistency. As far as this case is concerned, the only thing you
>> would have to worry about would be a veto from someone, and since
>> Emmanuel was the only dissenting voice, perhaps he would want to weigh
>> in at this point. Emmanuel?
>>
>> I don't know if I would agree that Bloch has "codified this
>> expectation into the minds of developers." I've been developing in
>> Java for a long time and when I see a NPE, I immediately think this
>> results from an attempt to dereference a null reference. Judging from
>> the discussion here, I would think others feel the same way.
>>
>> On Mon, Sep 2, 2013 at 1:49 PM, Benedikt Ritter <be...@gmail.com>
>> wrote:
>> > Hey,
>> >
>> > sorry if I missunderstood your opinions (Gary and James).
>> > So do we call for a [VOTE]? I've never seen a vote thread for design
>> > related decisions so far.
>> >
>> > Benedikt
>> >
>> >
>> > 2013/9/2 James Carman <ja...@carmanconsulting.com>
>> >
>> >> I meant re-visit the decision to make sure we took everything into
>> >> consideration when choosing which way to go in this case. I say we
>> >> leave [lang] alone at this point.
>> >>
>> >>
>> >> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gu...@gmail.com>
>> wrote:
>> >> > How do you mean, "revisit?" I think changing [lang] at this late date
>> >> would
>> >> > be more trouble than it's worth.
>> >> >
>> >> > Matt
>> >> > On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com>
>> >> wrote:
>> >> >
>> >> >> I favor IAE, but I want to make sure we re-visit the decision made
>> for
>> >> >> [lang] when it chose to use NPE instead.
>> >> >>
>> >> >> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <garydgregory@gmail.com
>> >
>> >> >> wrote:
>> >> >> > It feels to me that this misrepresents the ideas expressed here,
>> or at
>> >> >> > least mine ;) I am neither indifferent or favor NPE. I favor IAE,
>> so
>> >> >> > does that mean I am nor "most people". If a person make these
>> kinds of
>> >> >> > statement, we might as well VOTE or argue-discuss some more...!
>> >> >> >
>> >> >> > Gary
>> >> >> >
>> >> >> > On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org>
>> wrote:
>> >> >> >
>> >> >> >> Look's like most people are either indifferent or favor NPE. So,
>> do
>> >> we
>> >> >> >> change this for [CSV]? The important thing is to give users an
>> >> >> expressive
>> >> >> >> message.
>> >> >> >>
>> >> >> >> Benedikt
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> 2013/8/30 Gary Gregory <ga...@gmail.com>
>> >> >> >>
>> >> >> >>> Surprisingly, a lot. At work, we have a lot of
>> >> frameworky/plugin-type
>> >> >> of
>> >> >> >>> code where we run operations on collections of things and we do
>> not
>> >> >> want
>> >> >> >>> "expected" errors to torpedo the whole processing flow, so we do
>> >> catch
>> >> >> >>> things like IAE and ISE. We do try to avoid catching Exception
>> if we
>> >> >> can
>> >> >> >>> help it.
>> >> >> >>>
>> >> >> >>> Gary
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <
>> gudnabrsam@gmail.com>
>> >> >> wrote:
>> >> >> >>>
>> >> >> >>>> How often do you really want to catch these?
>> >> >> >>>>
>> >> >> >>>> Matt
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>> >> garydgregory@gmail.com
>> >> >> >>>>> wrote:
>> >> >> >>>>
>> >> >> >>>>> Another perspective to think about is whether you want to write
>> >> code
>> >> >> >>>> like:
>> >> >> >>>>>
>> >> >> >>>>> try {
>> >> >> >>>>> // la-di-da
>> >> >> >>>>> } catch (NullPointerException e) {
>> >> >> >>>>> // garbage in!
>> >> >> >>>>> }
>> >> >> >>>>>
>> >> >> >>>>> or:
>> >> >> >>>>>
>> >> >> >>>>> try {
>> >> >> >>>>> // doo-wap-doo-wap
>> >> >> >>>>> } catch (IllegalArugumentException e) {
>> >> >> >>>>> // garbage in!
>> >> >> >>>>> }
>> >> >> >>>>>
>> >> >> >>>>> Catching NPE just smells funny to me.
>> >> >> >>>>>
>> >> >> >>>>> Gary
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com>
>> wrote:
>> >> >> >>>>>
>> >> >> >>>>>> The fact that NPE is documented in Bloch is quite important.
>> >> >> >>>>>>
>> >> >> >>>>>> Whatever we do choose, we should make sure to document all th
>> >> >> reasons
>> >> >> >>>>>> (pros and cons) somewhere other than just the mailing list!
>> >> >> >>>>>>
>> >> >> >>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com>
>> >> wrote:
>> >> >> >>>>>>> The discussion for [lang], none of whose participants have
>> >> weighed
>> >> >> >>> in
>> >> >> >>>>>> here,
>> >> >> >>>>>>> took place in late 2009 (so perhaps a little longer ago than
>> I
>> >> >> >>>> thought)
>> >> >> >>>>>> and
>> >> >> >>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
>> >> >> >>>> arguments
>> >> >> >>>>>> in
>> >> >> >>>>>>> [2].
>> >> >> >>>>>>>
>> >> >> >>>>>>> Matt
>> >> >> >>>>>>>
>> >> >> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
>> >> >> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>> >> >> >>>>>>>
>> >> >> >>>>>>>
>> >> >> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com>
>> >> wrote:
>> >> >> >>>>>>>
>> >> >> >>>>>>>> The JDK Javadoc says of NPE:
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> * Applications should throw instances of this class to
>> indicate
>> >> >> >>>>>>>> * other illegal uses of the <code>null</code> object.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> and of IAE:
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> * Thrown to indicate that a method has been passed an
>> illegal
>> >> or
>> >> >> >>>>>>>> * inappropriate argument.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> That says to me that we should throw IAE here.
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> The JDK does use NPE for parameter checks, but it also uses
>> >> IAE,
>> >> >> >>> for
>> >> >> >>>>>>>> example:
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
>> >> >> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
>> >> >> >>>>>>>> javax.management.relation.RoleList.add
>> >> >> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>> >> >> >>>>>>>>
>> >> >> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
>> >> >> >>>>>> adrian.crum@sandglass-software.com>
>> >> >> >>>>>>>> wrote:
>> >> >> >>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in
>> the
>> >> end
>> >> >> >>>>> they
>> >> >> >>>>>> all
>> >> >> >>>>>>>>> condense down to what Matt stated here: Those who favor NPE
>> >> cite
>> >> >> >>>> the
>> >> >> >>>>>> JDK
>> >> >> >>>>>>>>> classes as a pattern to follow, and those who favor IAE
>> say it
>> >> >> >>> is
>> >> >> >>>> a
>> >> >> >>>>>>>> better
>> >> >> >>>>>>>>> description of the problem. From my perspective, both are
>> >> valid
>> >> >> >>>>>>>> viewpoints,
>> >> >> >>>>>>>>> and a project simply needs to choose one. In the end, the
>> >> choice
>> >> >> >>>> is
>> >> >> >>>>>>>> neither
>> >> >> >>>>>>>>> "right" nor "wrong" - it is just a choice.
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> -Adrian
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> Let me stir the pot:
>> >> >> >>>>>>>>>> At a fundamental level I agree that a required
>> *argument*
>> >> >> >>>> should
>> >> >> >>>>>>>> throw
>> >> >> >>>>>>>>>> an
>> >> >> >>>>>>>>>> IllegalArgumentException when null is supplied. However,
>> >> ISTR
>> >> >> >>>> the
>> >> >> >>>>>>>>>> decision
>> >> >> >>>>>>>>>> to do otherwise in [lang] having been discussed on-list in
>> >> the
>> >> >> >>>>>>>>>> not-so-distant past, and the result of that discussion
>> being
>> >> >> >>> that
>> >> >> >>>>>> NPE is
>> >> >> >>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
>> >> >> >>>>>> characterize
>> >> >> >>>>>>>>>> the
>> >> >> >>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now,
>> >> [lang]
>> >> >> >>>> is
>> >> >> >>>>>> in a
>> >> >> >>>>>>>>>> slightly unique situation as its stated mission is to
>> >> >> >>> complement
>> >> >> >>>>> Java
>> >> >> >>>>>>>> SE,
>> >> >> >>>>>>>>>> so it could be argued that [lang] is under greater
>> pressure
>> >> to
>> >> >> >>>>>> conform
>> >> >> >>>>>>>> for
>> >> >> >>>>>>>>>> that reason. But my personal preference, in light of the
>> >> >> >>>> standing
>> >> >> >>>>>>>>>> decision
>> >> >> >>>>>>>>>> with [lang], would be for consistency throughout Commons
>> >> >> >>>> components
>> >> >> >>>>>>>>>> *despite* the fact that at a purely semantic level I agree
>> >> with
>> >> >> >>>> the
>> >> >> >>>>>>>>>> arguments in favor of IllegalArgumentException.
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> To summarize, +1 for NullPointerException from me.
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> Matt
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
>> >> >> >>>>> britter@apache.org
>> >> >> >>>>>>>
>> >> >> >>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
>> >> britter@apache.org
>> >> >> >>>>
>> >> >> >>>>>> wrote:
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> I've removed the generics in r1518974, thanks for
>> spotting
>> >> >> >>>> that
>> >> >> >>>>>> sebb.
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
>> >> >> >>>> important
>> >> >> >>>>>> thing
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> is
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> to
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> fail early.
>> >> >> >>>>>>>>>>>> ... and with a helpful message.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> I personally thing that NPE should be reserved for
>> >> signaling
>> >> >> >>>>> that
>> >> >> >>>>>>>> some
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> code
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> tried to invoke a method on a null reference.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> +1
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> In our case null is illegal because we know that some
>> code
>> >> >> >>>> later
>> >> >> >>>>>> on
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> would
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> break if we accept a null reference. So
>> >> >> >>> IllegalStateException
>> >> >> >>>>>> makes
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> sense.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> +1
>> >> >> >>>>>>>>>>> Sorry, I meant IAE of corse.
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> Imaging having a method that accepts an int and only
>> >> >> >>> positive
>> >> >> >>>>> ints
>> >> >> >>>>>>>> are
>> >> >> >>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
>> >> >> >>>> negative
>> >> >> >>>>>> int
>> >> >> >>>>>>>> is
>> >> >> >>>>>>>>>>>>> passed to that method and not a
>> NegativeIntegerException
>> >> (or
>> >> >> >>>>> what
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> ever).
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we
>> should
>> >> >> >>>> stick
>> >> >> >>>>> to
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> this.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> I don't think we have to do the same as LANG, so long as
>> >> the
>> >> >> >>>>>> Javadoc
>> >> >> >>>>>>>> is
>> >> >> >>>>>>>>>>>> clear.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> Feel free to change it. I'll leave it for now since
>> there
>> >> >> >>>>> doesn't
>> >> >> >>>>>>>> seem
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> to
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> be consensus?!
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
>> >> >> >>> NPE" I
>> >> >> >>>>>> think
>> >> >> >>>>>>>>>>>> we should stick with IAE, as it more clearly indicates
>> the
>> >> >> >>> the
>> >> >> >>>>>> problem
>> >> >> >>>>>>>>>>>> is not within the method throwing it.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> The problem with using NPE to flag parameter errors is
>> that
>> >> >> >>> it
>> >> >> >>>>>>>>>>>> confuses the user as to the likely cause.
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> Leave NPEs to the runtime system.
>> >> >> >>>>>>>>>>> agreed.
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> Benedikt
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
>> >> >> >>>> developers
>> >> >> >>>>>> have
>> >> >> >>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
>> >> >> >>> crap"
>> >> >> >>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
>> >> >> >>> seeing
>> >> >> >>>>>> those).
>> >> >> >>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not
>> even
>> >> >> >>>> know
>> >> >> >>>>> to
>> >> >> >>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
>> >> >> >>>> alarming,
>> >> >> >>>>>> IMHO.
>> >> >> >>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a
>> >> long
>> >> >> >>>> time
>> >> >> >>>>>> in
>> >> >> >>>>>>>>>>>>>> [lang], so be it.
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <
>> sebbaz@gmail.com>
>> >> >> >>>>> wrote:
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message
>> associated
>> >> >> >>> with
>> >> >> >>>>>> them.
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> So provided that the assertion generates the NPE
>> with a
>> >> >> >>>>> suitable
>> >> >> >>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
>> >> >> >>>> *should*
>> >> >> >>>>> be
>> >> >> >>>>>>>>>>>>>>> possible for the end user to distinguish the two
>> cases.
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the
>> cause is
>> >> >> >>>>> obvious
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> with
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> needing to look at the NPE message.
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> ==
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could
>> wrap
>> >> an
>> >> >> >>>> IAE
>> >> >> >>>>>> in
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> the
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> NPE:
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> npe = new NPE(msg);
>> >> >> >>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
>> >> >> >>>>>>>>>>>>>>> throw npe;
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> Or vice-vera, of course!
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> Not sure that gains anything, but it does make the
>> stack
>> >> >> >>>> trace
>> >> >> >>>>>> look
>> >> >> >>>>>>>>>>>>>>> more impressive!
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
>> >> >> >>>>>> james@carmanconsulting.com>
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I
>> don't
>> >> >> >>>> know
>> >> >> >>>>>> that
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> I've
>> >> >> >>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
>> >> >> >>> decision
>> >> >> >>>>> was
>> >> >> >>>>>>>> made
>> >> >> >>>>>>>>>>>>>>>> that null constraint violations should throw NPEs.
>> >> Food
>> >> >> >>>> for
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> thought.
>> >> >> >>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> garydgregory@gmail.com>
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> ebourg@apache.org>
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> wrote:
>> >> >> >>>>>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
>> >> >> >>>>>>>>>>>>>>>>>>>> + throw new
>> >> >> >>>>> IllegalArgumentException("Parameter
>> >> >> >>>>>> '"
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> +
>> >> >> >>>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
>> >> >> >>>>>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>>>> + }
>> >> >> >>>>>>>>>>>>>>>>>>>> + }
>> >> >> >>>>>>>>>>>>>>>>>>>> +}
>> >> >> >>>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>> >> >> >>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume
>> something
>> >> is
>> >> >> >>>> very
>> >> >> >>>>>>>> wrong
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> and
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> that
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site,
>> >> somewhere
>> >> >> >>> on
>> >> >> >>>>> the
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> code
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> path.
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the
>> >> call
>> >> >> >>>> site
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> (which
>> >> >> >>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>> could
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> be a bug of course).
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent,
>> so
>> >> >> >>> it's
>> >> >> >>>>>> hard to
>> >> >> >>>>>>>>>>>>
>> >> >> >>>>>>>>>>>> find
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> examples.
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> Gary
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>> Emmanuel Bourg
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >> >>>> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>>>> dev-help@commons.apache.org
>> >> >> >>>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>>> --
>> >> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com |
>> ggregory@apache.org
>> >> >> >>>>>>>>>>>>>>>>> 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
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >> >>> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>>> dev-help@commons.apache.org
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >> >>> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>>> dev-help@commons.apache.org
>> >> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >> >>> dev-help@commons.apache.org
>> >> >> >>>>>>>>>>>>>
>> >> >> >>>>>>>>>>>>> --
>> >> >> >>>>>>>>>>>>> http://people.apache.org/~britter/
>> >> >> >>>>>>>>>>>>> http://www.systemoutprintln.de/
>> >> >> >>>>>>>>>>>>> http://twitter.com/BenediktRitter
>> >> >> >>>>>>>>>>>>> http://github.com/britter
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>>>>> For additional commands, e-mail:
>> >> dev-help@commons.apache.org
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>> --
>> >> >> >>>>>>>>>>> http://people.apache.org/~britter/
>> >> >> >>>>>>>>>>> http://www.systemoutprintln.de/
>> >> >> >>>>>>>>>>> http://twitter.com/BenediktRitter
>> >> >> >>>>>>>>>>> http://github.com/britter
>> >> >> >>>>>
>> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> >> >>>>
>> >> ---------------------------------------------------------------------
>> >> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> >>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> >>>>> 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
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> >>> 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
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> http://people.apache.org/~britter/
>> >> >> >> http://www.systemoutprintln.de/
>> >> >> >> http://twitter.com/BenediktRitter
>> >> >> >> http://github.com/britter
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
To continue to play devil's advocate, when one validates that an argument
is not null, doesn't this signify that in the absence of such validation,
NPE is what would be thrown anyway? Arguably throwing NPE from
Validate#notNull() simply allows the API designer to explicitly address
this and optionally provide a more detailed exception message in the
process.
Matt
On Mon, Sep 2, 2013 at 1:46 PM, James Carman <ja...@carmanconsulting.com>wrote:
> I think Emmanuel Bourg was the only one actually advocating NPE (or
> asking if it's what should be used). I brought up the fact that
> [lang] uses NPE merely as a discussion point. I don't agree with the
> NPE usage for Validate.notNull() (sorry I was not more clear on that
> opinion). I would rather have all of Validate's methods throw IAE for
> consistency. As far as this case is concerned, the only thing you
> would have to worry about would be a veto from someone, and since
> Emmanuel was the only dissenting voice, perhaps he would want to weigh
> in at this point. Emmanuel?
>
> I don't know if I would agree that Bloch has "codified this
> expectation into the minds of developers." I've been developing in
> Java for a long time and when I see a NPE, I immediately think this
> results from an attempt to dereference a null reference. Judging from
> the discussion here, I would think others feel the same way.
>
> On Mon, Sep 2, 2013 at 1:49 PM, Benedikt Ritter <be...@gmail.com>
> wrote:
> > Hey,
> >
> > sorry if I missunderstood your opinions (Gary and James).
> > So do we call for a [VOTE]? I've never seen a vote thread for design
> > related decisions so far.
> >
> > Benedikt
> >
> >
> > 2013/9/2 James Carman <ja...@carmanconsulting.com>
> >
> >> I meant re-visit the decision to make sure we took everything into
> >> consideration when choosing which way to go in this case. I say we
> >> leave [lang] alone at this point.
> >>
> >>
> >> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gu...@gmail.com>
> wrote:
> >> > How do you mean, "revisit?" I think changing [lang] at this late date
> >> would
> >> > be more trouble than it's worth.
> >> >
> >> > Matt
> >> > On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com>
> >> wrote:
> >> >
> >> >> I favor IAE, but I want to make sure we re-visit the decision made
> for
> >> >> [lang] when it chose to use NPE instead.
> >> >>
> >> >> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <garydgregory@gmail.com
> >
> >> >> wrote:
> >> >> > It feels to me that this misrepresents the ideas expressed here,
> or at
> >> >> > least mine ;) I am neither indifferent or favor NPE. I favor IAE,
> so
> >> >> > does that mean I am nor "most people". If a person make these
> kinds of
> >> >> > statement, we might as well VOTE or argue-discuss some more...!
> >> >> >
> >> >> > Gary
> >> >> >
> >> >> > On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org>
> wrote:
> >> >> >
> >> >> >> Look's like most people are either indifferent or favor NPE. So,
> do
> >> we
> >> >> >> change this for [CSV]? The important thing is to give users an
> >> >> expressive
> >> >> >> message.
> >> >> >>
> >> >> >> Benedikt
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> 2013/8/30 Gary Gregory <ga...@gmail.com>
> >> >> >>
> >> >> >>> Surprisingly, a lot. At work, we have a lot of
> >> frameworky/plugin-type
> >> >> of
> >> >> >>> code where we run operations on collections of things and we do
> not
> >> >> want
> >> >> >>> "expected" errors to torpedo the whole processing flow, so we do
> >> catch
> >> >> >>> things like IAE and ISE. We do try to avoid catching Exception
> if we
> >> >> can
> >> >> >>> help it.
> >> >> >>>
> >> >> >>> Gary
> >> >> >>>
> >> >> >>>
> >> >> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <
> gudnabrsam@gmail.com>
> >> >> wrote:
> >> >> >>>
> >> >> >>>> How often do you really want to catch these?
> >> >> >>>>
> >> >> >>>> Matt
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
> >> garydgregory@gmail.com
> >> >> >>>>> wrote:
> >> >> >>>>
> >> >> >>>>> Another perspective to think about is whether you want to write
> >> code
> >> >> >>>> like:
> >> >> >>>>>
> >> >> >>>>> try {
> >> >> >>>>> // la-di-da
> >> >> >>>>> } catch (NullPointerException e) {
> >> >> >>>>> // garbage in!
> >> >> >>>>> }
> >> >> >>>>>
> >> >> >>>>> or:
> >> >> >>>>>
> >> >> >>>>> try {
> >> >> >>>>> // doo-wap-doo-wap
> >> >> >>>>> } catch (IllegalArugumentException e) {
> >> >> >>>>> // garbage in!
> >> >> >>>>> }
> >> >> >>>>>
> >> >> >>>>> Catching NPE just smells funny to me.
> >> >> >>>>>
> >> >> >>>>> Gary
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com>
> wrote:
> >> >> >>>>>
> >> >> >>>>>> The fact that NPE is documented in Bloch is quite important.
> >> >> >>>>>>
> >> >> >>>>>> Whatever we do choose, we should make sure to document all th
> >> >> reasons
> >> >> >>>>>> (pros and cons) somewhere other than just the mailing list!
> >> >> >>>>>>
> >> >> >>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com>
> >> wrote:
> >> >> >>>>>>> The discussion for [lang], none of whose participants have
> >> weighed
> >> >> >>> in
> >> >> >>>>>> here,
> >> >> >>>>>>> took place in late 2009 (so perhaps a little longer ago than
> I
> >> >> >>>> thought)
> >> >> >>>>>> and
> >> >> >>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
> >> >> >>>> arguments
> >> >> >>>>>> in
> >> >> >>>>>>> [2].
> >> >> >>>>>>>
> >> >> >>>>>>> Matt
> >> >> >>>>>>>
> >> >> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> >> >> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com>
> >> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>> The JDK Javadoc says of NPE:
> >> >> >>>>>>>>
> >> >> >>>>>>>> * Applications should throw instances of this class to
> indicate
> >> >> >>>>>>>> * other illegal uses of the <code>null</code> object.
> >> >> >>>>>>>>
> >> >> >>>>>>>> and of IAE:
> >> >> >>>>>>>>
> >> >> >>>>>>>> * Thrown to indicate that a method has been passed an
> illegal
> >> or
> >> >> >>>>>>>> * inappropriate argument.
> >> >> >>>>>>>>
> >> >> >>>>>>>> That says to me that we should throw IAE here.
> >> >> >>>>>>>>
> >> >> >>>>>>>> The JDK does use NPE for parameter checks, but it also uses
> >> IAE,
> >> >> >>> for
> >> >> >>>>>>>> example:
> >> >> >>>>>>>>
> >> >> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
> >> >> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
> >> >> >>>>>>>> javax.management.relation.RoleList.add
> >> >> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> >> >> >>>>>>>>
> >> >> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
> >> >> >>>>>> adrian.crum@sandglass-software.com>
> >> >> >>>>>>>> wrote:
> >> >> >>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in
> the
> >> end
> >> >> >>>>> they
> >> >> >>>>>> all
> >> >> >>>>>>>>> condense down to what Matt stated here: Those who favor NPE
> >> cite
> >> >> >>>> the
> >> >> >>>>>> JDK
> >> >> >>>>>>>>> classes as a pattern to follow, and those who favor IAE
> say it
> >> >> >>> is
> >> >> >>>> a
> >> >> >>>>>>>> better
> >> >> >>>>>>>>> description of the problem. From my perspective, both are
> >> valid
> >> >> >>>>>>>> viewpoints,
> >> >> >>>>>>>>> and a project simply needs to choose one. In the end, the
> >> choice
> >> >> >>>> is
> >> >> >>>>>>>> neither
> >> >> >>>>>>>>> "right" nor "wrong" - it is just a choice.
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> -Adrian
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> Let me stir the pot:
> >> >> >>>>>>>>>> At a fundamental level I agree that a required
> *argument*
> >> >> >>>> should
> >> >> >>>>>>>> throw
> >> >> >>>>>>>>>> an
> >> >> >>>>>>>>>> IllegalArgumentException when null is supplied. However,
> >> ISTR
> >> >> >>>> the
> >> >> >>>>>>>>>> decision
> >> >> >>>>>>>>>> to do otherwise in [lang] having been discussed on-list in
> >> the
> >> >> >>>>>>>>>> not-so-distant past, and the result of that discussion
> being
> >> >> >>> that
> >> >> >>>>>> NPE is
> >> >> >>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
> >> >> >>>>>> characterize
> >> >> >>>>>>>>>> the
> >> >> >>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now,
> >> [lang]
> >> >> >>>> is
> >> >> >>>>>> in a
> >> >> >>>>>>>>>> slightly unique situation as its stated mission is to
> >> >> >>> complement
> >> >> >>>>> Java
> >> >> >>>>>>>> SE,
> >> >> >>>>>>>>>> so it could be argued that [lang] is under greater
> pressure
> >> to
> >> >> >>>>>> conform
> >> >> >>>>>>>> for
> >> >> >>>>>>>>>> that reason. But my personal preference, in light of the
> >> >> >>>> standing
> >> >> >>>>>>>>>> decision
> >> >> >>>>>>>>>> with [lang], would be for consistency throughout Commons
> >> >> >>>> components
> >> >> >>>>>>>>>> *despite* the fact that at a purely semantic level I agree
> >> with
> >> >> >>>> the
> >> >> >>>>>>>>>> arguments in favor of IllegalArgumentException.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> To summarize, +1 for NullPointerException from me.
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> Matt
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
> >> >> >>>>> britter@apache.org
> >> >> >>>>>>>
> >> >> >>>>>>>>>> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
> >> britter@apache.org
> >> >> >>>>
> >> >> >>>>>> wrote:
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> I've removed the generics in r1518974, thanks for
> spotting
> >> >> >>>> that
> >> >> >>>>>> sebb.
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
> >> >> >>>> important
> >> >> >>>>>> thing
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> is
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> to
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> fail early.
> >> >> >>>>>>>>>>>> ... and with a helpful message.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> I personally thing that NPE should be reserved for
> >> signaling
> >> >> >>>>> that
> >> >> >>>>>>>> some
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> code
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> tried to invoke a method on a null reference.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> +1
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> In our case null is illegal because we know that some
> code
> >> >> >>>> later
> >> >> >>>>>> on
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> would
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> break if we accept a null reference. So
> >> >> >>> IllegalStateException
> >> >> >>>>>> makes
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> sense.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> +1
> >> >> >>>>>>>>>>> Sorry, I meant IAE of corse.
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>>> Imaging having a method that accepts an int and only
> >> >> >>> positive
> >> >> >>>>> ints
> >> >> >>>>>>>> are
> >> >> >>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
> >> >> >>>> negative
> >> >> >>>>>> int
> >> >> >>>>>>>> is
> >> >> >>>>>>>>>>>>> passed to that method and not a
> NegativeIntegerException
> >> (or
> >> >> >>>>> what
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> ever).
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we
> should
> >> >> >>>> stick
> >> >> >>>>> to
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> this.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> I don't think we have to do the same as LANG, so long as
> >> the
> >> >> >>>>>> Javadoc
> >> >> >>>>>>>> is
> >> >> >>>>>>>>>>>> clear.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> Feel free to change it. I'll leave it for now since
> there
> >> >> >>>>> doesn't
> >> >> >>>>>>>> seem
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> to
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> be consensus?!
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
> >> >> >>> NPE" I
> >> >> >>>>>> think
> >> >> >>>>>>>>>>>> we should stick with IAE, as it more clearly indicates
> the
> >> >> >>> the
> >> >> >>>>>> problem
> >> >> >>>>>>>>>>>> is not within the method throwing it.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> The problem with using NPE to flag parameter errors is
> that
> >> >> >>> it
> >> >> >>>>>>>>>>>> confuses the user as to the likely cause.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Leave NPEs to the runtime system.
> >> >> >>>>>>>>>>> agreed.
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>>> Benedikt
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
> >> >> >>>> developers
> >> >> >>>>>> have
> >> >> >>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
> >> >> >>> crap"
> >> >> >>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
> >> >> >>> seeing
> >> >> >>>>>> those).
> >> >> >>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not
> even
> >> >> >>>> know
> >> >> >>>>> to
> >> >> >>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
> >> >> >>>> alarming,
> >> >> >>>>>> IMHO.
> >> >> >>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a
> >> long
> >> >> >>>> time
> >> >> >>>>>> in
> >> >> >>>>>>>>>>>>>> [lang], so be it.
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <
> sebbaz@gmail.com>
> >> >> >>>>> wrote:
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message
> associated
> >> >> >>> with
> >> >> >>>>>> them.
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> So provided that the assertion generates the NPE
> with a
> >> >> >>>>> suitable
> >> >> >>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
> >> >> >>>> *should*
> >> >> >>>>> be
> >> >> >>>>>>>>>>>>>>> possible for the end user to distinguish the two
> cases.
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the
> cause is
> >> >> >>>>> obvious
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> with
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> needing to look at the NPE message.
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> ==
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could
> wrap
> >> an
> >> >> >>>> IAE
> >> >> >>>>>> in
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> the
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> NPE:
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> npe = new NPE(msg);
> >> >> >>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
> >> >> >>>>>>>>>>>>>>> throw npe;
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> Or vice-vera, of course!
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> Not sure that gains anything, but it does make the
> stack
> >> >> >>>> trace
> >> >> >>>>>> look
> >> >> >>>>>>>>>>>>>>> more impressive!
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
> >> >> >>>>>> james@carmanconsulting.com>
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I
> don't
> >> >> >>>> know
> >> >> >>>>>> that
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> I've
> >> >> >>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
> >> >> >>> decision
> >> >> >>>>> was
> >> >> >>>>>>>> made
> >> >> >>>>>>>>>>>>>>>> that null constraint violations should throw NPEs.
> >> Food
> >> >> >>>> for
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> thought.
> >> >> >>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> garydgregory@gmail.com>
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> ebourg@apache.org>
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
> >> >> >>>>>>>>>>>>>>>>>>>> + throw new
> >> >> >>>>> IllegalArgumentException("Parameter
> >> >> >>>>>> '"
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> +
> >> >> >>>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
> >> >> >>>>>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>>>> + }
> >> >> >>>>>>>>>>>>>>>>>>>> + }
> >> >> >>>>>>>>>>>>>>>>>>>> +}
> >> >> >>>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> >> >> >>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume
> something
> >> is
> >> >> >>>> very
> >> >> >>>>>>>> wrong
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> and
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> that
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site,
> >> somewhere
> >> >> >>> on
> >> >> >>>>> the
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> code
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> path.
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the
> >> call
> >> >> >>>> site
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> (which
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> could
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> be a bug of course).
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent,
> so
> >> >> >>> it's
> >> >> >>>>>> hard to
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> find
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> examples.
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> Gary
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>> Emmanuel Bourg
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >> >>>> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>>>> dev-help@commons.apache.org
> >> >> >>>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>>> --
> >> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com |
> ggregory@apache.org
> >> >> >>>>>>>>>>>>>>>>> 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
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >> >>> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>>> dev-help@commons.apache.org
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >> >>> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>>> dev-help@commons.apache.org
> >> >> >>>>
> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>>>> For additional commands, e-mail:
> >> >> >>> dev-help@commons.apache.org
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> --
> >> >> >>>>>>>>>>>>> http://people.apache.org/~britter/
> >> >> >>>>>>>>>>>>> http://www.systemoutprintln.de/
> >> >> >>>>>>>>>>>>> http://twitter.com/BenediktRitter
> >> >> >>>>>>>>>>>>> http://github.com/britter
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>>>>> For additional commands, e-mail:
> >> dev-help@commons.apache.org
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>> --
> >> >> >>>>>>>>>>> http://people.apache.org/~britter/
> >> >> >>>>>>>>>>> http://www.systemoutprintln.de/
> >> >> >>>>>>>>>>> http://twitter.com/BenediktRitter
> >> >> >>>>>>>>>>> http://github.com/britter
> >> >> >>>>>
> >> ---------------------------------------------------------------------
> >> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> >> >>>>
> >> ---------------------------------------------------------------------
> >> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> >>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> --
> >> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> >>>>> 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
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> --
> >> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >> >>> 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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> http://people.apache.org/~britter/
> >> >> >> http://www.systemoutprintln.de/
> >> >> >> http://twitter.com/BenediktRitter
> >> >> >> http://github.com/britter
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
I think Emmanuel Bourg was the only one actually advocating NPE (or
asking if it's what should be used). I brought up the fact that
[lang] uses NPE merely as a discussion point. I don't agree with the
NPE usage for Validate.notNull() (sorry I was not more clear on that
opinion). I would rather have all of Validate's methods throw IAE for
consistency. As far as this case is concerned, the only thing you
would have to worry about would be a veto from someone, and since
Emmanuel was the only dissenting voice, perhaps he would want to weigh
in at this point. Emmanuel?
I don't know if I would agree that Bloch has "codified this
expectation into the minds of developers." I've been developing in
Java for a long time and when I see a NPE, I immediately think this
results from an attempt to dereference a null reference. Judging from
the discussion here, I would think others feel the same way.
On Mon, Sep 2, 2013 at 1:49 PM, Benedikt Ritter <be...@gmail.com> wrote:
> Hey,
>
> sorry if I missunderstood your opinions (Gary and James).
> So do we call for a [VOTE]? I've never seen a vote thread for design
> related decisions so far.
>
> Benedikt
>
>
> 2013/9/2 James Carman <ja...@carmanconsulting.com>
>
>> I meant re-visit the decision to make sure we took everything into
>> consideration when choosing which way to go in this case. I say we
>> leave [lang] alone at this point.
>>
>>
>> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gu...@gmail.com> wrote:
>> > How do you mean, "revisit?" I think changing [lang] at this late date
>> would
>> > be more trouble than it's worth.
>> >
>> > Matt
>> > On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com>
>> wrote:
>> >
>> >> I favor IAE, but I want to make sure we re-visit the decision made for
>> >> [lang] when it chose to use NPE instead.
>> >>
>> >> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <ga...@gmail.com>
>> >> wrote:
>> >> > It feels to me that this misrepresents the ideas expressed here, or at
>> >> > least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
>> >> > does that mean I am nor "most people". If a person make these kinds of
>> >> > statement, we might as well VOTE or argue-discuss some more...!
>> >> >
>> >> > Gary
>> >> >
>> >> > On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org> wrote:
>> >> >
>> >> >> Look's like most people are either indifferent or favor NPE. So, do
>> we
>> >> >> change this for [CSV]? The important thing is to give users an
>> >> expressive
>> >> >> message.
>> >> >>
>> >> >> Benedikt
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2013/8/30 Gary Gregory <ga...@gmail.com>
>> >> >>
>> >> >>> Surprisingly, a lot. At work, we have a lot of
>> frameworky/plugin-type
>> >> of
>> >> >>> code where we run operations on collections of things and we do not
>> >> want
>> >> >>> "expected" errors to torpedo the whole processing flow, so we do
>> catch
>> >> >>> things like IAE and ISE. We do try to avoid catching Exception if we
>> >> can
>> >> >>> help it.
>> >> >>>
>> >> >>> Gary
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com>
>> >> wrote:
>> >> >>>
>> >> >>>> How often do you really want to catch these?
>> >> >>>>
>> >> >>>> Matt
>> >> >>>>
>> >> >>>>
>> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
>> garydgregory@gmail.com
>> >> >>>>> wrote:
>> >> >>>>
>> >> >>>>> Another perspective to think about is whether you want to write
>> code
>> >> >>>> like:
>> >> >>>>>
>> >> >>>>> try {
>> >> >>>>> // la-di-da
>> >> >>>>> } catch (NullPointerException e) {
>> >> >>>>> // garbage in!
>> >> >>>>> }
>> >> >>>>>
>> >> >>>>> or:
>> >> >>>>>
>> >> >>>>> try {
>> >> >>>>> // doo-wap-doo-wap
>> >> >>>>> } catch (IllegalArugumentException e) {
>> >> >>>>> // garbage in!
>> >> >>>>> }
>> >> >>>>>
>> >> >>>>> Catching NPE just smells funny to me.
>> >> >>>>>
>> >> >>>>> Gary
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
>> >> >>>>>
>> >> >>>>>> The fact that NPE is documented in Bloch is quite important.
>> >> >>>>>>
>> >> >>>>>> Whatever we do choose, we should make sure to document all th
>> >> reasons
>> >> >>>>>> (pros and cons) somewhere other than just the mailing list!
>> >> >>>>>>
>> >> >>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com>
>> wrote:
>> >> >>>>>>> The discussion for [lang], none of whose participants have
>> weighed
>> >> >>> in
>> >> >>>>>> here,
>> >> >>>>>>> took place in late 2009 (so perhaps a little longer ago than I
>> >> >>>> thought)
>> >> >>>>>> and
>> >> >>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
>> >> >>>> arguments
>> >> >>>>>> in
>> >> >>>>>>> [2].
>> >> >>>>>>>
>> >> >>>>>>> Matt
>> >> >>>>>>>
>> >> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
>> >> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com>
>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>> The JDK Javadoc says of NPE:
>> >> >>>>>>>>
>> >> >>>>>>>> * Applications should throw instances of this class to indicate
>> >> >>>>>>>> * other illegal uses of the <code>null</code> object.
>> >> >>>>>>>>
>> >> >>>>>>>> and of IAE:
>> >> >>>>>>>>
>> >> >>>>>>>> * Thrown to indicate that a method has been passed an illegal
>> or
>> >> >>>>>>>> * inappropriate argument.
>> >> >>>>>>>>
>> >> >>>>>>>> That says to me that we should throw IAE here.
>> >> >>>>>>>>
>> >> >>>>>>>> The JDK does use NPE for parameter checks, but it also uses
>> IAE,
>> >> >>> for
>> >> >>>>>>>> example:
>> >> >>>>>>>>
>> >> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
>> >> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
>> >> >>>>>>>> javax.management.relation.RoleList.add
>> >> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>> >> >>>>>>>>
>> >> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
>> >> >>>>>> adrian.crum@sandglass-software.com>
>> >> >>>>>>>> wrote:
>> >> >>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in the
>> end
>> >> >>>>> they
>> >> >>>>>> all
>> >> >>>>>>>>> condense down to what Matt stated here: Those who favor NPE
>> cite
>> >> >>>> the
>> >> >>>>>> JDK
>> >> >>>>>>>>> classes as a pattern to follow, and those who favor IAE say it
>> >> >>> is
>> >> >>>> a
>> >> >>>>>>>> better
>> >> >>>>>>>>> description of the problem. From my perspective, both are
>> valid
>> >> >>>>>>>> viewpoints,
>> >> >>>>>>>>> and a project simply needs to choose one. In the end, the
>> choice
>> >> >>>> is
>> >> >>>>>>>> neither
>> >> >>>>>>>>> "right" nor "wrong" - it is just a choice.
>> >> >>>>>>>>>
>> >> >>>>>>>>> -Adrian
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Let me stir the pot:
>> >> >>>>>>>>>> At a fundamental level I agree that a required *argument*
>> >> >>>> should
>> >> >>>>>>>> throw
>> >> >>>>>>>>>> an
>> >> >>>>>>>>>> IllegalArgumentException when null is supplied. However,
>> ISTR
>> >> >>>> the
>> >> >>>>>>>>>> decision
>> >> >>>>>>>>>> to do otherwise in [lang] having been discussed on-list in
>> the
>> >> >>>>>>>>>> not-so-distant past, and the result of that discussion being
>> >> >>> that
>> >> >>>>>> NPE is
>> >> >>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
>> >> >>>>>> characterize
>> >> >>>>>>>>>> the
>> >> >>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now,
>> [lang]
>> >> >>>> is
>> >> >>>>>> in a
>> >> >>>>>>>>>> slightly unique situation as its stated mission is to
>> >> >>> complement
>> >> >>>>> Java
>> >> >>>>>>>> SE,
>> >> >>>>>>>>>> so it could be argued that [lang] is under greater pressure
>> to
>> >> >>>>>> conform
>> >> >>>>>>>> for
>> >> >>>>>>>>>> that reason. But my personal preference, in light of the
>> >> >>>> standing
>> >> >>>>>>>>>> decision
>> >> >>>>>>>>>> with [lang], would be for consistency throughout Commons
>> >> >>>> components
>> >> >>>>>>>>>> *despite* the fact that at a purely semantic level I agree
>> with
>> >> >>>> the
>> >> >>>>>>>>>> arguments in favor of IllegalArgumentException.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> To summarize, +1 for NullPointerException from me.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Matt
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
>> >> >>>>> britter@apache.org
>> >> >>>>>>>
>> >> >>>>>>>>>> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
>> britter@apache.org
>> >> >>>>
>> >> >>>>>> wrote:
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> I've removed the generics in r1518974, thanks for spotting
>> >> >>>> that
>> >> >>>>>> sebb.
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
>> >> >>>> important
>> >> >>>>>> thing
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> is
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> to
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> fail early.
>> >> >>>>>>>>>>>> ... and with a helpful message.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>> I personally thing that NPE should be reserved for
>> signaling
>> >> >>>>> that
>> >> >>>>>>>> some
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> code
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> tried to invoke a method on a null reference.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> +1
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>> In our case null is illegal because we know that some code
>> >> >>>> later
>> >> >>>>>> on
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> would
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> break if we accept a null reference. So
>> >> >>> IllegalStateException
>> >> >>>>>> makes
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> sense.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> +1
>> >> >>>>>>>>>>> Sorry, I meant IAE of corse.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>>> Imaging having a method that accepts an int and only
>> >> >>> positive
>> >> >>>>> ints
>> >> >>>>>>>> are
>> >> >>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
>> >> >>>> negative
>> >> >>>>>> int
>> >> >>>>>>>> is
>> >> >>>>>>>>>>>>> passed to that method and not a NegativeIntegerException
>> (or
>> >> >>>>> what
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> ever).
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we should
>> >> >>>> stick
>> >> >>>>> to
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> this.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I don't think we have to do the same as LANG, so long as
>> the
>> >> >>>>>> Javadoc
>> >> >>>>>>>> is
>> >> >>>>>>>>>>>> clear.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Feel free to change it. I'll leave it for now since there
>> >> >>>>> doesn't
>> >> >>>>>>>> seem
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> to
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> be consensus?!
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
>> >> >>> NPE" I
>> >> >>>>>> think
>> >> >>>>>>>>>>>> we should stick with IAE, as it more clearly indicates the
>> >> >>> the
>> >> >>>>>> problem
>> >> >>>>>>>>>>>> is not within the method throwing it.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> The problem with using NPE to flag parameter errors is that
>> >> >>> it
>> >> >>>>>>>>>>>> confuses the user as to the likely cause.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Leave NPEs to the runtime system.
>> >> >>>>>>>>>>> agreed.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>>> Benedikt
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
>> >> >>>> developers
>> >> >>>>>> have
>> >> >>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
>> >> >>> crap"
>> >> >>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
>> >> >>> seeing
>> >> >>>>>> those).
>> >> >>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not even
>> >> >>>> know
>> >> >>>>> to
>> >> >>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
>> >> >>>> alarming,
>> >> >>>>>> IMHO.
>> >> >>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a
>> long
>> >> >>>> time
>> >> >>>>>> in
>> >> >>>>>>>>>>>>>> [lang], so be it.
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
>> >> >>>>> wrote:
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message associated
>> >> >>> with
>> >> >>>>>> them.
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> So provided that the assertion generates the NPE with a
>> >> >>>>> suitable
>> >> >>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
>> >> >>>> *should*
>> >> >>>>> be
>> >> >>>>>>>>>>>>>>> possible for the end user to distinguish the two cases.
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the cause is
>> >> >>>>> obvious
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> with
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> needing to look at the NPE message.
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> ==
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could wrap
>> an
>> >> >>>> IAE
>> >> >>>>>> in
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> the
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> NPE:
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> npe = new NPE(msg);
>> >> >>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
>> >> >>>>>>>>>>>>>>> throw npe;
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> Or vice-vera, of course!
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> Not sure that gains anything, but it does make the stack
>> >> >>>> trace
>> >> >>>>>> look
>> >> >>>>>>>>>>>>>>> more impressive!
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
>> >> >>>>>> james@carmanconsulting.com>
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> wrote:
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
>> >> >>>> know
>> >> >>>>>> that
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> I've
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
>> >> >>> decision
>> >> >>>>> was
>> >> >>>>>>>> made
>> >> >>>>>>>>>>>>>>>> that null constraint violations should throw NPEs.
>> Food
>> >> >>>> for
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> thought.
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> garydgregory@gmail.com>
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> wrote:
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> ebourg@apache.org>
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> wrote:
>> >> >>>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
>> >> >>>>>>>>>>>>>>>>>>>> + throw new
>> >> >>>>> IllegalArgumentException("Parameter
>> >> >>>>>> '"
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> +
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
>> >> >>>>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>>>> + }
>> >> >>>>>>>>>>>>>>>>>>>> + }
>> >> >>>>>>>>>>>>>>>>>>>> +}
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>> >> >>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume something
>> is
>> >> >>>> very
>> >> >>>>>>>> wrong
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> and
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> that
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site,
>> somewhere
>> >> >>> on
>> >> >>>>> the
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> code
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> path.
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the
>> call
>> >> >>>> site
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> (which
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> could
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> be a bug of course).
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
>> >> >>> it's
>> >> >>>>>> hard to
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> find
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> examples.
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> Gary
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> Emmanuel Bourg
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >>>> dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>>>> dev-help@commons.apache.org
>> >> >>>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>>> --
>> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >>>>>>>>>>>>>>>>> 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
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >>> dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>>> dev-help@commons.apache.org
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >> >>> dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>>> dev-help@commons.apache.org
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>>>> For additional commands, e-mail:
>> >> >>> dev-help@commons.apache.org
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> --
>> >> >>>>>>>>>>>>> http://people.apache.org/~britter/
>> >> >>>>>>>>>>>>> http://www.systemoutprintln.de/
>> >> >>>>>>>>>>>>> http://twitter.com/BenediktRitter
>> >> >>>>>>>>>>>>> http://github.com/britter
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> --
>> >> >>>>>>>>>>> http://people.apache.org/~britter/
>> >> >>>>>>>>>>> http://www.systemoutprintln.de/
>> >> >>>>>>>>>>> http://twitter.com/BenediktRitter
>> >> >>>>>>>>>>> http://github.com/britter
>> >> >>>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >>>>> 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
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >>> 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
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> http://people.apache.org/~britter/
>> >> >> http://www.systemoutprintln.de/
>> >> >> http://twitter.com/BenediktRitter
>> >> >> http://github.com/britter
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Benedikt Ritter <be...@gmail.com>.
Hey,
sorry if I missunderstood your opinions (Gary and James).
So do we call for a [VOTE]? I've never seen a vote thread for design
related decisions so far.
Benedikt
2013/9/2 James Carman <ja...@carmanconsulting.com>
> I meant re-visit the decision to make sure we took everything into
> consideration when choosing which way to go in this case. I say we
> leave [lang] alone at this point.
>
>
> On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gu...@gmail.com> wrote:
> > How do you mean, "revisit?" I think changing [lang] at this late date
> would
> > be more trouble than it's worth.
> >
> > Matt
> > On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
> >
> >> I favor IAE, but I want to make sure we re-visit the decision made for
> >> [lang] when it chose to use NPE instead.
> >>
> >> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >> > It feels to me that this misrepresents the ideas expressed here, or at
> >> > least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
> >> > does that mean I am nor "most people". If a person make these kinds of
> >> > statement, we might as well VOTE or argue-discuss some more...!
> >> >
> >> > Gary
> >> >
> >> > On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org> wrote:
> >> >
> >> >> Look's like most people are either indifferent or favor NPE. So, do
> we
> >> >> change this for [CSV]? The important thing is to give users an
> >> expressive
> >> >> message.
> >> >>
> >> >> Benedikt
> >> >>
> >> >>
> >> >>
> >> >> 2013/8/30 Gary Gregory <ga...@gmail.com>
> >> >>
> >> >>> Surprisingly, a lot. At work, we have a lot of
> frameworky/plugin-type
> >> of
> >> >>> code where we run operations on collections of things and we do not
> >> want
> >> >>> "expected" errors to torpedo the whole processing flow, so we do
> catch
> >> >>> things like IAE and ISE. We do try to avoid catching Exception if we
> >> can
> >> >>> help it.
> >> >>>
> >> >>> Gary
> >> >>>
> >> >>>
> >> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com>
> >> wrote:
> >> >>>
> >> >>>> How often do you really want to catch these?
> >> >>>>
> >> >>>> Matt
> >> >>>>
> >> >>>>
> >> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <
> garydgregory@gmail.com
> >> >>>>> wrote:
> >> >>>>
> >> >>>>> Another perspective to think about is whether you want to write
> code
> >> >>>> like:
> >> >>>>>
> >> >>>>> try {
> >> >>>>> // la-di-da
> >> >>>>> } catch (NullPointerException e) {
> >> >>>>> // garbage in!
> >> >>>>> }
> >> >>>>>
> >> >>>>> or:
> >> >>>>>
> >> >>>>> try {
> >> >>>>> // doo-wap-doo-wap
> >> >>>>> } catch (IllegalArugumentException e) {
> >> >>>>> // garbage in!
> >> >>>>> }
> >> >>>>>
> >> >>>>> Catching NPE just smells funny to me.
> >> >>>>>
> >> >>>>> Gary
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
> >> >>>>>
> >> >>>>>> The fact that NPE is documented in Bloch is quite important.
> >> >>>>>>
> >> >>>>>> Whatever we do choose, we should make sure to document all th
> >> reasons
> >> >>>>>> (pros and cons) somewhere other than just the mailing list!
> >> >>>>>>
> >> >>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com>
> wrote:
> >> >>>>>>> The discussion for [lang], none of whose participants have
> weighed
> >> >>> in
> >> >>>>>> here,
> >> >>>>>>> took place in late 2009 (so perhaps a little longer ago than I
> >> >>>> thought)
> >> >>>>>> and
> >> >>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
> >> >>>> arguments
> >> >>>>>> in
> >> >>>>>>> [2].
> >> >>>>>>>
> >> >>>>>>> Matt
> >> >>>>>>>
> >> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> >> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com>
> wrote:
> >> >>>>>>>
> >> >>>>>>>> The JDK Javadoc says of NPE:
> >> >>>>>>>>
> >> >>>>>>>> * Applications should throw instances of this class to indicate
> >> >>>>>>>> * other illegal uses of the <code>null</code> object.
> >> >>>>>>>>
> >> >>>>>>>> and of IAE:
> >> >>>>>>>>
> >> >>>>>>>> * Thrown to indicate that a method has been passed an illegal
> or
> >> >>>>>>>> * inappropriate argument.
> >> >>>>>>>>
> >> >>>>>>>> That says to me that we should throw IAE here.
> >> >>>>>>>>
> >> >>>>>>>> The JDK does use NPE for parameter checks, but it also uses
> IAE,
> >> >>> for
> >> >>>>>>>> example:
> >> >>>>>>>>
> >> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
> >> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
> >> >>>>>>>> javax.management.relation.RoleList.add
> >> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> >> >>>>>>>>
> >> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
> >> >>>>>> adrian.crum@sandglass-software.com>
> >> >>>>>>>> wrote:
> >> >>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in the
> end
> >> >>>>> they
> >> >>>>>> all
> >> >>>>>>>>> condense down to what Matt stated here: Those who favor NPE
> cite
> >> >>>> the
> >> >>>>>> JDK
> >> >>>>>>>>> classes as a pattern to follow, and those who favor IAE say it
> >> >>> is
> >> >>>> a
> >> >>>>>>>> better
> >> >>>>>>>>> description of the problem. From my perspective, both are
> valid
> >> >>>>>>>> viewpoints,
> >> >>>>>>>>> and a project simply needs to choose one. In the end, the
> choice
> >> >>>> is
> >> >>>>>>>> neither
> >> >>>>>>>>> "right" nor "wrong" - it is just a choice.
> >> >>>>>>>>>
> >> >>>>>>>>> -Adrian
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>> Let me stir the pot:
> >> >>>>>>>>>> At a fundamental level I agree that a required *argument*
> >> >>>> should
> >> >>>>>>>> throw
> >> >>>>>>>>>> an
> >> >>>>>>>>>> IllegalArgumentException when null is supplied. However,
> ISTR
> >> >>>> the
> >> >>>>>>>>>> decision
> >> >>>>>>>>>> to do otherwise in [lang] having been discussed on-list in
> the
> >> >>>>>>>>>> not-so-distant past, and the result of that discussion being
> >> >>> that
> >> >>>>>> NPE is
> >> >>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
> >> >>>>>> characterize
> >> >>>>>>>>>> the
> >> >>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now,
> [lang]
> >> >>>> is
> >> >>>>>> in a
> >> >>>>>>>>>> slightly unique situation as its stated mission is to
> >> >>> complement
> >> >>>>> Java
> >> >>>>>>>> SE,
> >> >>>>>>>>>> so it could be argued that [lang] is under greater pressure
> to
> >> >>>>>> conform
> >> >>>>>>>> for
> >> >>>>>>>>>> that reason. But my personal preference, in light of the
> >> >>>> standing
> >> >>>>>>>>>> decision
> >> >>>>>>>>>> with [lang], would be for consistency throughout Commons
> >> >>>> components
> >> >>>>>>>>>> *despite* the fact that at a purely semantic level I agree
> with
> >> >>>> the
> >> >>>>>>>>>> arguments in favor of IllegalArgumentException.
> >> >>>>>>>>>>
> >> >>>>>>>>>> To summarize, +1 for NullPointerException from me.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Matt
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
> >> >>>>> britter@apache.org
> >> >>>>>>>
> >> >>>>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <
> britter@apache.org
> >> >>>>
> >> >>>>>> wrote:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> I've removed the generics in r1518974, thanks for spotting
> >> >>>> that
> >> >>>>>> sebb.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
> >> >>>> important
> >> >>>>>> thing
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> is
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> fail early.
> >> >>>>>>>>>>>> ... and with a helpful message.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> I personally thing that NPE should be reserved for
> signaling
> >> >>>>> that
> >> >>>>>>>> some
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> code
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> tried to invoke a method on a null reference.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> +1
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> In our case null is illegal because we know that some code
> >> >>>> later
> >> >>>>>> on
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> would
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> break if we accept a null reference. So
> >> >>> IllegalStateException
> >> >>>>>> makes
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> sense.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> +1
> >> >>>>>>>>>>> Sorry, I meant IAE of corse.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>> Imaging having a method that accepts an int and only
> >> >>> positive
> >> >>>>> ints
> >> >>>>>>>> are
> >> >>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
> >> >>>> negative
> >> >>>>>> int
> >> >>>>>>>> is
> >> >>>>>>>>>>>>> passed to that method and not a NegativeIntegerException
> (or
> >> >>>>> what
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> ever).
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we should
> >> >>>> stick
> >> >>>>> to
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> this.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I don't think we have to do the same as LANG, so long as
> the
> >> >>>>>> Javadoc
> >> >>>>>>>> is
> >> >>>>>>>>>>>> clear.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> Feel free to change it. I'll leave it for now since there
> >> >>>>> doesn't
> >> >>>>>>>> seem
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> to
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> be consensus?!
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
> >> >>> NPE" I
> >> >>>>>> think
> >> >>>>>>>>>>>> we should stick with IAE, as it more clearly indicates the
> >> >>> the
> >> >>>>>> problem
> >> >>>>>>>>>>>> is not within the method throwing it.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> The problem with using NPE to flag parameter errors is that
> >> >>> it
> >> >>>>>>>>>>>> confuses the user as to the likely cause.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Leave NPEs to the runtime system.
> >> >>>>>>>>>>> agreed.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>> Benedikt
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
> >> >>>> developers
> >> >>>>>> have
> >> >>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
> >> >>> crap"
> >> >>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
> >> >>> seeing
> >> >>>>>> those).
> >> >>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not even
> >> >>>> know
> >> >>>>> to
> >> >>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
> >> >>>> alarming,
> >> >>>>>> IMHO.
> >> >>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a
> long
> >> >>>> time
> >> >>>>>> in
> >> >>>>>>>>>>>>>> [lang], so be it.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
> >> >>>>> wrote:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message associated
> >> >>> with
> >> >>>>>> them.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> So provided that the assertion generates the NPE with a
> >> >>>>> suitable
> >> >>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
> >> >>>> *should*
> >> >>>>> be
> >> >>>>>>>>>>>>>>> possible for the end user to distinguish the two cases.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the cause is
> >> >>>>> obvious
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> with
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> needing to look at the NPE message.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> ==
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could wrap
> an
> >> >>>> IAE
> >> >>>>>> in
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> the
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> NPE:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> npe = new NPE(msg);
> >> >>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
> >> >>>>>>>>>>>>>>> throw npe;
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Or vice-vera, of course!
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> Not sure that gains anything, but it does make the stack
> >> >>>> trace
> >> >>>>>> look
> >> >>>>>>>>>>>>>>> more impressive!
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
> >> >>>>>> james@carmanconsulting.com>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
> >> >>>> know
> >> >>>>>> that
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> I've
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
> >> >>> decision
> >> >>>>> was
> >> >>>>>>>> made
> >> >>>>>>>>>>>>>>>> that null constraint violations should throw NPEs.
> Food
> >> >>>> for
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> thought.
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> garydgregory@gmail.com>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> ebourg@apache.org>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
> >> >>>>>>>>>>>>>>>>>>>> + throw new
> >> >>>>> IllegalArgumentException("Parameter
> >> >>>>>> '"
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> +
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
> >> >>>>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>>> + }
> >> >>>>>>>>>>>>>>>>>>>> + }
> >> >>>>>>>>>>>>>>>>>>>> +}
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> >> >>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume something
> is
> >> >>>> very
> >> >>>>>>>> wrong
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> and
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> that
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site,
> somewhere
> >> >>> on
> >> >>>>> the
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> code
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> path.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the
> call
> >> >>>> site
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> (which
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> could
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> be a bug of course).
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
> >> >>> it's
> >> >>>>>> hard to
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> find
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> examples.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> Gary
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> Emmanuel Bourg
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >>>> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>>>> dev-help@commons.apache.org
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>> --
> >> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>>>>>>>>>>>>>>> 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
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >>> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>>> dev-help@commons.apache.org
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> >>> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>>> dev-help@commons.apache.org
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>>>> For additional commands, e-mail:
> >> >>> dev-help@commons.apache.org
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> --
> >> >>>>>>>>>>>>> http://people.apache.org/~britter/
> >> >>>>>>>>>>>>> http://www.systemoutprintln.de/
> >> >>>>>>>>>>>>> http://twitter.com/BenediktRitter
> >> >>>>>>>>>>>>> http://github.com/britter
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> --
> >> >>>>>>>>>>> http://people.apache.org/~britter/
> >> >>>>>>>>>>> http://www.systemoutprintln.de/
> >> >>>>>>>>>>> http://twitter.com/BenediktRitter
> >> >>>>>>>>>>> http://github.com/britter
> >> >>>>>
> ---------------------------------------------------------------------
> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>>> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>> 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
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> http://people.apache.org/~britter/
> >> >> http://www.systemoutprintln.de/
> >> >> http://twitter.com/BenediktRitter
> >> >> http://github.com/britter
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
I meant re-visit the decision to make sure we took everything into
consideration when choosing which way to go in this case. I say we
leave [lang] alone at this point.
On Mon, Sep 2, 2013 at 11:41 AM, Matt Benson <gu...@gmail.com> wrote:
> How do you mean, "revisit?" I think changing [lang] at this late date would
> be more trouble than it's worth.
>
> Matt
> On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
>
>> I favor IAE, but I want to make sure we re-visit the decision made for
>> [lang] when it chose to use NPE instead.
>>
>> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> > It feels to me that this misrepresents the ideas expressed here, or at
>> > least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
>> > does that mean I am nor "most people". If a person make these kinds of
>> > statement, we might as well VOTE or argue-discuss some more...!
>> >
>> > Gary
>> >
>> > On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org> wrote:
>> >
>> >> Look's like most people are either indifferent or favor NPE. So, do we
>> >> change this for [CSV]? The important thing is to give users an
>> expressive
>> >> message.
>> >>
>> >> Benedikt
>> >>
>> >>
>> >>
>> >> 2013/8/30 Gary Gregory <ga...@gmail.com>
>> >>
>> >>> Surprisingly, a lot. At work, we have a lot of frameworky/plugin-type
>> of
>> >>> code where we run operations on collections of things and we do not
>> want
>> >>> "expected" errors to torpedo the whole processing flow, so we do catch
>> >>> things like IAE and ISE. We do try to avoid catching Exception if we
>> can
>> >>> help it.
>> >>>
>> >>> Gary
>> >>>
>> >>>
>> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com>
>> wrote:
>> >>>
>> >>>> How often do you really want to catch these?
>> >>>>
>> >>>> Matt
>> >>>>
>> >>>>
>> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@gmail.com
>> >>>>> wrote:
>> >>>>
>> >>>>> Another perspective to think about is whether you want to write code
>> >>>> like:
>> >>>>>
>> >>>>> try {
>> >>>>> // la-di-da
>> >>>>> } catch (NullPointerException e) {
>> >>>>> // garbage in!
>> >>>>> }
>> >>>>>
>> >>>>> or:
>> >>>>>
>> >>>>> try {
>> >>>>> // doo-wap-doo-wap
>> >>>>> } catch (IllegalArugumentException e) {
>> >>>>> // garbage in!
>> >>>>> }
>> >>>>>
>> >>>>> Catching NPE just smells funny to me.
>> >>>>>
>> >>>>> Gary
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
>> >>>>>
>> >>>>>> The fact that NPE is documented in Bloch is quite important.
>> >>>>>>
>> >>>>>> Whatever we do choose, we should make sure to document all th
>> reasons
>> >>>>>> (pros and cons) somewhere other than just the mailing list!
>> >>>>>>
>> >>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
>> >>>>>>> The discussion for [lang], none of whose participants have weighed
>> >>> in
>> >>>>>> here,
>> >>>>>>> took place in late 2009 (so perhaps a little longer ago than I
>> >>>> thought)
>> >>>>>> and
>> >>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
>> >>>> arguments
>> >>>>>> in
>> >>>>>>> [2].
>> >>>>>>>
>> >>>>>>> Matt
>> >>>>>>>
>> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
>> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>> The JDK Javadoc says of NPE:
>> >>>>>>>>
>> >>>>>>>> * Applications should throw instances of this class to indicate
>> >>>>>>>> * other illegal uses of the <code>null</code> object.
>> >>>>>>>>
>> >>>>>>>> and of IAE:
>> >>>>>>>>
>> >>>>>>>> * Thrown to indicate that a method has been passed an illegal or
>> >>>>>>>> * inappropriate argument.
>> >>>>>>>>
>> >>>>>>>> That says to me that we should throw IAE here.
>> >>>>>>>>
>> >>>>>>>> The JDK does use NPE for parameter checks, but it also uses IAE,
>> >>> for
>> >>>>>>>> example:
>> >>>>>>>>
>> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
>> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
>> >>>>>>>> javax.management.relation.RoleList.add
>> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>> >>>>>>>>
>> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
>> >>>>>> adrian.crum@sandglass-software.com>
>> >>>>>>>> wrote:
>> >>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in the end
>> >>>>> they
>> >>>>>> all
>> >>>>>>>>> condense down to what Matt stated here: Those who favor NPE cite
>> >>>> the
>> >>>>>> JDK
>> >>>>>>>>> classes as a pattern to follow, and those who favor IAE say it
>> >>> is
>> >>>> a
>> >>>>>>>> better
>> >>>>>>>>> description of the problem. From my perspective, both are valid
>> >>>>>>>> viewpoints,
>> >>>>>>>>> and a project simply needs to choose one. In the end, the choice
>> >>>> is
>> >>>>>>>> neither
>> >>>>>>>>> "right" nor "wrong" - it is just a choice.
>> >>>>>>>>>
>> >>>>>>>>> -Adrian
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Let me stir the pot:
>> >>>>>>>>>> At a fundamental level I agree that a required *argument*
>> >>>> should
>> >>>>>>>> throw
>> >>>>>>>>>> an
>> >>>>>>>>>> IllegalArgumentException when null is supplied. However, ISTR
>> >>>> the
>> >>>>>>>>>> decision
>> >>>>>>>>>> to do otherwise in [lang] having been discussed on-list in the
>> >>>>>>>>>> not-so-distant past, and the result of that discussion being
>> >>> that
>> >>>>>> NPE is
>> >>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
>> >>>>>> characterize
>> >>>>>>>>>> the
>> >>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now, [lang]
>> >>>> is
>> >>>>>> in a
>> >>>>>>>>>> slightly unique situation as its stated mission is to
>> >>> complement
>> >>>>> Java
>> >>>>>>>> SE,
>> >>>>>>>>>> so it could be argued that [lang] is under greater pressure to
>> >>>>>> conform
>> >>>>>>>> for
>> >>>>>>>>>> that reason. But my personal preference, in light of the
>> >>>> standing
>> >>>>>>>>>> decision
>> >>>>>>>>>> with [lang], would be for consistency throughout Commons
>> >>>> components
>> >>>>>>>>>> *despite* the fact that at a purely semantic level I agree with
>> >>>> the
>> >>>>>>>>>> arguments in favor of IllegalArgumentException.
>> >>>>>>>>>>
>> >>>>>>>>>> To summarize, +1 for NullPointerException from me.
>> >>>>>>>>>>
>> >>>>>>>>>> Matt
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
>> >>>>> britter@apache.org
>> >>>>>>>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@apache.org
>> >>>>
>> >>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I've removed the generics in r1518974, thanks for spotting
>> >>>> that
>> >>>>>> sebb.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
>> >>>> important
>> >>>>>> thing
>> >>>>>>>>>>>
>> >>>>>>>>>>> is
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> fail early.
>> >>>>>>>>>>>> ... and with a helpful message.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> I personally thing that NPE should be reserved for signaling
>> >>>>> that
>> >>>>>>>> some
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> code
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> tried to invoke a method on a null reference.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> +1
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> In our case null is illegal because we know that some code
>> >>>> later
>> >>>>>> on
>> >>>>>>>>>>>
>> >>>>>>>>>>> would
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> break if we accept a null reference. So
>> >>> IllegalStateException
>> >>>>>> makes
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> sense.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> +1
>> >>>>>>>>>>> Sorry, I meant IAE of corse.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>> Imaging having a method that accepts an int and only
>> >>> positive
>> >>>>> ints
>> >>>>>>>> are
>> >>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
>> >>>> negative
>> >>>>>> int
>> >>>>>>>> is
>> >>>>>>>>>>>>> passed to that method and not a NegativeIntegerException (or
>> >>>>> what
>> >>>>>>>>>>>
>> >>>>>>>>>>> ever).
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we should
>> >>>> stick
>> >>>>> to
>> >>>>>>>>>>>
>> >>>>>>>>>>> this.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I don't think we have to do the same as LANG, so long as the
>> >>>>>> Javadoc
>> >>>>>>>> is
>> >>>>>>>>>>>> clear.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Feel free to change it. I'll leave it for now since there
>> >>>>> doesn't
>> >>>>>>>> seem
>> >>>>>>>>>>>
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> be consensus?!
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
>> >>> NPE" I
>> >>>>>> think
>> >>>>>>>>>>>> we should stick with IAE, as it more clearly indicates the
>> >>> the
>> >>>>>> problem
>> >>>>>>>>>>>> is not within the method throwing it.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> The problem with using NPE to flag parameter errors is that
>> >>> it
>> >>>>>>>>>>>> confuses the user as to the likely cause.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Leave NPEs to the runtime system.
>> >>>>>>>>>>> agreed.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>> Benedikt
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
>> >>>> developers
>> >>>>>> have
>> >>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
>> >>> crap"
>> >>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
>> >>> seeing
>> >>>>>> those).
>> >>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not even
>> >>>> know
>> >>>>> to
>> >>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
>> >>>> alarming,
>> >>>>>> IMHO.
>> >>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a long
>> >>>> time
>> >>>>>> in
>> >>>>>>>>>>>>>> [lang], so be it.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
>> >>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message associated
>> >>> with
>> >>>>>> them.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> So provided that the assertion generates the NPE with a
>> >>>>> suitable
>> >>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
>> >>>> *should*
>> >>>>> be
>> >>>>>>>>>>>>>>> possible for the end user to distinguish the two cases.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the cause is
>> >>>>> obvious
>> >>>>>>>>>>>
>> >>>>>>>>>>> with
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> needing to look at the NPE message.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> ==
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could wrap an
>> >>>> IAE
>> >>>>>> in
>> >>>>>>>>>>>
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> NPE:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> npe = new NPE(msg);
>> >>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
>> >>>>>>>>>>>>>>> throw npe;
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Or vice-vera, of course!
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Not sure that gains anything, but it does make the stack
>> >>>> trace
>> >>>>>> look
>> >>>>>>>>>>>>>>> more impressive!
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
>> >>>>>> james@carmanconsulting.com>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
>> >>>> know
>> >>>>>> that
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I've
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
>> >>> decision
>> >>>>> was
>> >>>>>>>> made
>> >>>>>>>>>>>>>>>> that null constraint violations should throw NPEs. Food
>> >>>> for
>> >>>>>>>>>>>
>> >>>>>>>>>>> thought.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> garydgregory@gmail.com>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >>>>>>>>>>>
>> >>>>>>>>>>> ebourg@apache.org>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
>> >>>>>>>>>>>>>>>>>>>> + throw new
>> >>>>> IllegalArgumentException("Parameter
>> >>>>>> '"
>> >>>>>>>>>>>
>> >>>>>>>>>>> +
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> + }
>> >>>>>>>>>>>>>>>>>>>> + }
>> >>>>>>>>>>>>>>>>>>>> +}
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>> >>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume something is
>> >>>> very
>> >>>>>>>> wrong
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> and
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site, somewhere
>> >>> on
>> >>>>> the
>> >>>>>>>>>>>
>> >>>>>>>>>>> code
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> path.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the call
>> >>>> site
>> >>>>>>>>>>>
>> >>>>>>>>>>> (which
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> could
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> be a bug of course).
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
>> >>> it's
>> >>>>>> hard to
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> find
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> examples.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Gary
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Emmanuel Bourg
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >>>> dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>>> dev-help@commons.apache.org
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>>>>>>>>>>>>>>>> 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
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >>> dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>> dev-help@commons.apache.org
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >>> dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>> dev-help@commons.apache.org
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>>>> For additional commands, e-mail:
>> >>> dev-help@commons.apache.org
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> --
>> >>>>>>>>>>>>> http://people.apache.org/~britter/
>> >>>>>>>>>>>>> http://www.systemoutprintln.de/
>> >>>>>>>>>>>>> http://twitter.com/BenediktRitter
>> >>>>>>>>>>>>> http://github.com/britter
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> http://people.apache.org/~britter/
>> >>>>>>>>>>> http://www.systemoutprintln.de/
>> >>>>>>>>>>> http://twitter.com/BenediktRitter
>> >>>>>>>>>>> http://github.com/britter
>> >>>>> ---------------------------------------------------------------------
>> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>>>> 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
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>> 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
>> >>
>> >>
>> >>
>> >> --
>> >> http://people.apache.org/~britter/
>> >> http://www.systemoutprintln.de/
>> >> http://twitter.com/BenediktRitter
>> >> http://github.com/britter
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
How do you mean, "revisit?" I think changing [lang] at this late date would
be more trouble than it's worth.
Matt
On Sep 1, 2013 1:31 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
> I favor IAE, but I want to make sure we re-visit the decision made for
> [lang] when it chose to use NPE instead.
>
> On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> > It feels to me that this misrepresents the ideas expressed here, or at
> > least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
> > does that mean I am nor "most people". If a person make these kinds of
> > statement, we might as well VOTE or argue-discuss some more...!
> >
> > Gary
> >
> > On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org> wrote:
> >
> >> Look's like most people are either indifferent or favor NPE. So, do we
> >> change this for [CSV]? The important thing is to give users an
> expressive
> >> message.
> >>
> >> Benedikt
> >>
> >>
> >>
> >> 2013/8/30 Gary Gregory <ga...@gmail.com>
> >>
> >>> Surprisingly, a lot. At work, we have a lot of frameworky/plugin-type
> of
> >>> code where we run operations on collections of things and we do not
> want
> >>> "expected" errors to torpedo the whole processing flow, so we do catch
> >>> things like IAE and ISE. We do try to avoid catching Exception if we
> can
> >>> help it.
> >>>
> >>> Gary
> >>>
> >>>
> >>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com>
> wrote:
> >>>
> >>>> How often do you really want to catch these?
> >>>>
> >>>> Matt
> >>>>
> >>>>
> >>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@gmail.com
> >>>>> wrote:
> >>>>
> >>>>> Another perspective to think about is whether you want to write code
> >>>> like:
> >>>>>
> >>>>> try {
> >>>>> // la-di-da
> >>>>> } catch (NullPointerException e) {
> >>>>> // garbage in!
> >>>>> }
> >>>>>
> >>>>> or:
> >>>>>
> >>>>> try {
> >>>>> // doo-wap-doo-wap
> >>>>> } catch (IllegalArugumentException e) {
> >>>>> // garbage in!
> >>>>> }
> >>>>>
> >>>>> Catching NPE just smells funny to me.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
> >>>>>
> >>>>>> The fact that NPE is documented in Bloch is quite important.
> >>>>>>
> >>>>>> Whatever we do choose, we should make sure to document all th
> reasons
> >>>>>> (pros and cons) somewhere other than just the mailing list!
> >>>>>>
> >>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
> >>>>>>> The discussion for [lang], none of whose participants have weighed
> >>> in
> >>>>>> here,
> >>>>>>> took place in late 2009 (so perhaps a little longer ago than I
> >>>> thought)
> >>>>>> and
> >>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
> >>>> arguments
> >>>>>> in
> >>>>>>> [2].
> >>>>>>>
> >>>>>>> Matt
> >>>>>>>
> >>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> >>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> The JDK Javadoc says of NPE:
> >>>>>>>>
> >>>>>>>> * Applications should throw instances of this class to indicate
> >>>>>>>> * other illegal uses of the <code>null</code> object.
> >>>>>>>>
> >>>>>>>> and of IAE:
> >>>>>>>>
> >>>>>>>> * Thrown to indicate that a method has been passed an illegal or
> >>>>>>>> * inappropriate argument.
> >>>>>>>>
> >>>>>>>> That says to me that we should throw IAE here.
> >>>>>>>>
> >>>>>>>> The JDK does use NPE for parameter checks, but it also uses IAE,
> >>> for
> >>>>>>>> example:
> >>>>>>>>
> >>>>>>>> javax.management.monitor.Monitor.addObservedObject
> >>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
> >>>>>>>> javax.management.relation.RoleList.add
> >>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> >>>>>>>>
> >>>>>>>> On 30 August 2013 16:50, Adrian Crum <
> >>>>>> adrian.crum@sandglass-software.com>
> >>>>>>>> wrote:
> >>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in the end
> >>>>> they
> >>>>>> all
> >>>>>>>>> condense down to what Matt stated here: Those who favor NPE cite
> >>>> the
> >>>>>> JDK
> >>>>>>>>> classes as a pattern to follow, and those who favor IAE say it
> >>> is
> >>>> a
> >>>>>>>> better
> >>>>>>>>> description of the problem. From my perspective, both are valid
> >>>>>>>> viewpoints,
> >>>>>>>>> and a project simply needs to choose one. In the end, the choice
> >>>> is
> >>>>>>>> neither
> >>>>>>>>> "right" nor "wrong" - it is just a choice.
> >>>>>>>>>
> >>>>>>>>> -Adrian
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
> >>>>>>>>>>
> >>>>>>>>>> Let me stir the pot:
> >>>>>>>>>> At a fundamental level I agree that a required *argument*
> >>>> should
> >>>>>>>> throw
> >>>>>>>>>> an
> >>>>>>>>>> IllegalArgumentException when null is supplied. However, ISTR
> >>>> the
> >>>>>>>>>> decision
> >>>>>>>>>> to do otherwise in [lang] having been discussed on-list in the
> >>>>>>>>>> not-so-distant past, and the result of that discussion being
> >>> that
> >>>>>> NPE is
> >>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
> >>>>>> characterize
> >>>>>>>>>> the
> >>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now, [lang]
> >>>> is
> >>>>>> in a
> >>>>>>>>>> slightly unique situation as its stated mission is to
> >>> complement
> >>>>> Java
> >>>>>>>> SE,
> >>>>>>>>>> so it could be argued that [lang] is under greater pressure to
> >>>>>> conform
> >>>>>>>> for
> >>>>>>>>>> that reason. But my personal preference, in light of the
> >>>> standing
> >>>>>>>>>> decision
> >>>>>>>>>> with [lang], would be for consistency throughout Commons
> >>>> components
> >>>>>>>>>> *despite* the fact that at a purely semantic level I agree with
> >>>> the
> >>>>>>>>>> arguments in favor of IllegalArgumentException.
> >>>>>>>>>>
> >>>>>>>>>> To summarize, +1 for NullPointerException from me.
> >>>>>>>>>>
> >>>>>>>>>> Matt
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
> >>>>> britter@apache.org
> >>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@apache.org
> >>>>
> >>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've removed the generics in r1518974, thanks for spotting
> >>>> that
> >>>>>> sebb.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
> >>>> important
> >>>>>> thing
> >>>>>>>>>>>
> >>>>>>>>>>> is
> >>>>>>>>>>>>
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> fail early.
> >>>>>>>>>>>> ... and with a helpful message.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I personally thing that NPE should be reserved for signaling
> >>>>> that
> >>>>>>>> some
> >>>>>>>>>>>>
> >>>>>>>>>>>> code
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> tried to invoke a method on a null reference.
> >>>>>>>>>>>>
> >>>>>>>>>>>> +1
> >>>>>>>>>>>>
> >>>>>>>>>>>>> In our case null is illegal because we know that some code
> >>>> later
> >>>>>> on
> >>>>>>>>>>>
> >>>>>>>>>>> would
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> break if we accept a null reference. So
> >>> IllegalStateException
> >>>>>> makes
> >>>>>>>>>>>>
> >>>>>>>>>>>> sense.
> >>>>>>>>>>>>
> >>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
> >>>>>>>>>>>>
> >>>>>>>>>>>> +1
> >>>>>>>>>>> Sorry, I meant IAE of corse.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> Imaging having a method that accepts an int and only
> >>> positive
> >>>>> ints
> >>>>>>>> are
> >>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
> >>>> negative
> >>>>>> int
> >>>>>>>> is
> >>>>>>>>>>>>> passed to that method and not a NegativeIntegerException (or
> >>>>> what
> >>>>>>>>>>>
> >>>>>>>>>>> ever).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we should
> >>>> stick
> >>>>> to
> >>>>>>>>>>>
> >>>>>>>>>>> this.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I don't think we have to do the same as LANG, so long as the
> >>>>>> Javadoc
> >>>>>>>> is
> >>>>>>>>>>>> clear.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Feel free to change it. I'll leave it for now since there
> >>>>> doesn't
> >>>>>>>> seem
> >>>>>>>>>>>
> >>>>>>>>>>> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> be consensus?!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
> >>> NPE" I
> >>>>>> think
> >>>>>>>>>>>> we should stick with IAE, as it more clearly indicates the
> >>> the
> >>>>>> problem
> >>>>>>>>>>>> is not within the method throwing it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The problem with using NPE to flag parameter errors is that
> >>> it
> >>>>>>>>>>>> confuses the user as to the likely cause.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Leave NPEs to the runtime system.
> >>>>>>>>>>> agreed.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> Benedikt
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
> >>>> developers
> >>>>>> have
> >>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
> >>> crap"
> >>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
> >>> seeing
> >>>>>> those).
> >>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not even
> >>>> know
> >>>>> to
> >>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
> >>>> alarming,
> >>>>>> IMHO.
> >>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a long
> >>>> time
> >>>>>> in
> >>>>>>>>>>>>>> [lang], so be it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
> >>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message associated
> >>> with
> >>>>>> them.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So provided that the assertion generates the NPE with a
> >>>>> suitable
> >>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
> >>>> *should*
> >>>>> be
> >>>>>>>>>>>>>>> possible for the end user to distinguish the two cases.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the cause is
> >>>>> obvious
> >>>>>>>>>>>
> >>>>>>>>>>> with
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> needing to look at the NPE message.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> ==
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could wrap an
> >>>> IAE
> >>>>>> in
> >>>>>>>>>>>
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> NPE:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> npe = new NPE(msg);
> >>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
> >>>>>>>>>>>>>>> throw npe;
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Or vice-vera, of course!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Not sure that gains anything, but it does make the stack
> >>>> trace
> >>>>>> look
> >>>>>>>>>>>>>>> more impressive!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
> >>>>>> james@carmanconsulting.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
> >>>> know
> >>>>>> that
> >>>>>>>>>>>>
> >>>>>>>>>>>> I've
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
> >>> decision
> >>>>> was
> >>>>>>>> made
> >>>>>>>>>>>>>>>> that null constraint violations should throw NPEs. Food
> >>>> for
> >>>>>>>>>>>
> >>>>>>>>>>> thought.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> >>>>>>>>>>>>
> >>>>>>>>>>>> garydgregory@gmail.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >>>>>>>>>>>
> >>>>>>>>>>> ebourg@apache.org>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
> >>>>>>>>>>>>>>>>>>>> + throw new
> >>>>> IllegalArgumentException("Parameter
> >>>>>> '"
> >>>>>>>>>>>
> >>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> + }
> >>>>>>>>>>>>>>>>>>>> + }
> >>>>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> >>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume something is
> >>>> very
> >>>>>>>> wrong
> >>>>>>>>>>>>
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site, somewhere
> >>> on
> >>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>> code
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> path.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the call
> >>>> site
> >>>>>>>>>>>
> >>>>>>>>>>> (which
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> be a bug of course).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
> >>> it's
> >>>>>> hard to
> >>>>>>>>>>>>
> >>>>>>>>>>>> find
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> examples.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Gary
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Emmanuel Bourg
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >>>> dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>> dev-help@commons.apache.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>>>>>>>>>>>>>>> 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
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>> dev-help@commons.apache.org
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>> dev-help@commons.apache.org
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> >>> dev-help@commons.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> http://people.apache.org/~britter/
> >>>>>>>>>>>>> http://www.systemoutprintln.de/
> >>>>>>>>>>>>> http://twitter.com/BenediktRitter
> >>>>>>>>>>>>> http://github.com/britter
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> http://people.apache.org/~britter/
> >>>>>>>>>>> http://www.systemoutprintln.de/
> >>>>>>>>>>> http://twitter.com/BenediktRitter
> >>>>>>>>>>> http://github.com/britter
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>>> --
> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>>> 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
> >>>
> >>>
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> 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
> >>
> >>
> >>
> >> --
> >> http://people.apache.org/~britter/
> >> http://www.systemoutprintln.de/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
I favor IAE, but I want to make sure we re-visit the decision made for
[lang] when it chose to use NPE instead.
On Sun, Sep 1, 2013 at 1:37 PM, Gary Gregory <ga...@gmail.com> wrote:
> It feels to me that this misrepresents the ideas expressed here, or at
> least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
> does that mean I am nor "most people". If a person make these kinds of
> statement, we might as well VOTE or argue-discuss some more...!
>
> Gary
>
> On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org> wrote:
>
>> Look's like most people are either indifferent or favor NPE. So, do we
>> change this for [CSV]? The important thing is to give users an expressive
>> message.
>>
>> Benedikt
>>
>>
>>
>> 2013/8/30 Gary Gregory <ga...@gmail.com>
>>
>>> Surprisingly, a lot. At work, we have a lot of frameworky/plugin-type of
>>> code where we run operations on collections of things and we do not want
>>> "expected" errors to torpedo the whole processing flow, so we do catch
>>> things like IAE and ISE. We do try to avoid catching Exception if we can
>>> help it.
>>>
>>> Gary
>>>
>>>
>>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com> wrote:
>>>
>>>> How often do you really want to catch these?
>>>>
>>>> Matt
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@gmail.com
>>>>> wrote:
>>>>
>>>>> Another perspective to think about is whether you want to write code
>>>> like:
>>>>>
>>>>> try {
>>>>> // la-di-da
>>>>> } catch (NullPointerException e) {
>>>>> // garbage in!
>>>>> }
>>>>>
>>>>> or:
>>>>>
>>>>> try {
>>>>> // doo-wap-doo-wap
>>>>> } catch (IllegalArugumentException e) {
>>>>> // garbage in!
>>>>> }
>>>>>
>>>>> Catching NPE just smells funny to me.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> The fact that NPE is documented in Bloch is quite important.
>>>>>>
>>>>>> Whatever we do choose, we should make sure to document all th reasons
>>>>>> (pros and cons) somewhere other than just the mailing list!
>>>>>>
>>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
>>>>>>> The discussion for [lang], none of whose participants have weighed
>>> in
>>>>>> here,
>>>>>>> took place in late 2009 (so perhaps a little longer ago than I
>>>> thought)
>>>>>> and
>>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
>>>> arguments
>>>>>> in
>>>>>>> [2].
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
>>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>>> The JDK Javadoc says of NPE:
>>>>>>>>
>>>>>>>> * Applications should throw instances of this class to indicate
>>>>>>>> * other illegal uses of the <code>null</code> object.
>>>>>>>>
>>>>>>>> and of IAE:
>>>>>>>>
>>>>>>>> * Thrown to indicate that a method has been passed an illegal or
>>>>>>>> * inappropriate argument.
>>>>>>>>
>>>>>>>> That says to me that we should throw IAE here.
>>>>>>>>
>>>>>>>> The JDK does use NPE for parameter checks, but it also uses IAE,
>>> for
>>>>>>>> example:
>>>>>>>>
>>>>>>>> javax.management.monitor.Monitor.addObservedObject
>>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
>>>>>>>> javax.management.relation.RoleList.add
>>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>>>>>>>>
>>>>>>>> On 30 August 2013 16:50, Adrian Crum <
>>>>>> adrian.crum@sandglass-software.com>
>>>>>>>> wrote:
>>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in the end
>>>>> they
>>>>>> all
>>>>>>>>> condense down to what Matt stated here: Those who favor NPE cite
>>>> the
>>>>>> JDK
>>>>>>>>> classes as a pattern to follow, and those who favor IAE say it
>>> is
>>>> a
>>>>>>>> better
>>>>>>>>> description of the problem. From my perspective, both are valid
>>>>>>>> viewpoints,
>>>>>>>>> and a project simply needs to choose one. In the end, the choice
>>>> is
>>>>>>>> neither
>>>>>>>>> "right" nor "wrong" - it is just a choice.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
>>>>>>>>>>
>>>>>>>>>> Let me stir the pot:
>>>>>>>>>> At a fundamental level I agree that a required *argument*
>>>> should
>>>>>>>> throw
>>>>>>>>>> an
>>>>>>>>>> IllegalArgumentException when null is supplied. However, ISTR
>>>> the
>>>>>>>>>> decision
>>>>>>>>>> to do otherwise in [lang] having been discussed on-list in the
>>>>>>>>>> not-so-distant past, and the result of that discussion being
>>> that
>>>>>> NPE is
>>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
>>>>>> characterize
>>>>>>>>>> the
>>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now, [lang]
>>>> is
>>>>>> in a
>>>>>>>>>> slightly unique situation as its stated mission is to
>>> complement
>>>>> Java
>>>>>>>> SE,
>>>>>>>>>> so it could be argued that [lang] is under greater pressure to
>>>>>> conform
>>>>>>>> for
>>>>>>>>>> that reason. But my personal preference, in light of the
>>>> standing
>>>>>>>>>> decision
>>>>>>>>>> with [lang], would be for consistency throughout Commons
>>>> components
>>>>>>>>>> *despite* the fact that at a purely semantic level I agree with
>>>> the
>>>>>>>>>> arguments in favor of IllegalArgumentException.
>>>>>>>>>>
>>>>>>>>>> To summarize, +1 for NullPointerException from me.
>>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
>>>>> britter@apache.org
>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@apache.org
>>>>
>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've removed the generics in r1518974, thanks for spotting
>>>> that
>>>>>> sebb.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
>>>> important
>>>>>> thing
>>>>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>> fail early.
>>>>>>>>>>>> ... and with a helpful message.
>>>>>>>>>>>>
>>>>>>>>>>>>> I personally thing that NPE should be reserved for signaling
>>>>> that
>>>>>>>> some
>>>>>>>>>>>>
>>>>>>>>>>>> code
>>>>>>>>>>>>>
>>>>>>>>>>>>> tried to invoke a method on a null reference.
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>>> In our case null is illegal because we know that some code
>>>> later
>>>>>> on
>>>>>>>>>>>
>>>>>>>>>>> would
>>>>>>>>>>>>>
>>>>>>>>>>>>> break if we accept a null reference. So
>>> IllegalStateException
>>>>>> makes
>>>>>>>>>>>>
>>>>>>>>>>>> sense.
>>>>>>>>>>>>
>>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>> Sorry, I meant IAE of corse.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Imaging having a method that accepts an int and only
>>> positive
>>>>> ints
>>>>>>>> are
>>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
>>>> negative
>>>>>> int
>>>>>>>> is
>>>>>>>>>>>>> passed to that method and not a NegativeIntegerException (or
>>>>> what
>>>>>>>>>>>
>>>>>>>>>>> ever).
>>>>>>>>>>>>>
>>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we should
>>>> stick
>>>>> to
>>>>>>>>>>>
>>>>>>>>>>> this.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think we have to do the same as LANG, so long as the
>>>>>> Javadoc
>>>>>>>> is
>>>>>>>>>>>> clear.
>>>>>>>>>>>>
>>>>>>>>>>>>> Feel free to change it. I'll leave it for now since there
>>>>> doesn't
>>>>>>>> seem
>>>>>>>>>>>
>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>> be consensus?!
>>>>>>>>>>>>
>>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
>>> NPE" I
>>>>>> think
>>>>>>>>>>>> we should stick with IAE, as it more clearly indicates the
>>> the
>>>>>> problem
>>>>>>>>>>>> is not within the method throwing it.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with using NPE to flag parameter errors is that
>>> it
>>>>>>>>>>>> confuses the user as to the likely cause.
>>>>>>>>>>>>
>>>>>>>>>>>> Leave NPEs to the runtime system.
>>>>>>>>>>> agreed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Benedikt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
>>>> developers
>>>>>> have
>>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
>>> crap"
>>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
>>> seeing
>>>>>> those).
>>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not even
>>>> know
>>>>> to
>>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
>>>> alarming,
>>>>>> IMHO.
>>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a long
>>>> time
>>>>>> in
>>>>>>>>>>>>>> [lang], so be it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message associated
>>> with
>>>>>> them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So provided that the assertion generates the NPE with a
>>>>> suitable
>>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
>>>> *should*
>>>>> be
>>>>>>>>>>>>>>> possible for the end user to distinguish the two cases.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the cause is
>>>>> obvious
>>>>>>>>>>>
>>>>>>>>>>> with
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> needing to look at the NPE message.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ==
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could wrap an
>>>> IAE
>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NPE:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> npe = new NPE(msg);
>>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
>>>>>>>>>>>>>>> throw npe;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or vice-vera, of course!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure that gains anything, but it does make the stack
>>>> trace
>>>>>> look
>>>>>>>>>>>>>>> more impressive!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
>>>>>> james@carmanconsulting.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
>>>> know
>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>> I've
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
>>> decision
>>>>> was
>>>>>>>> made
>>>>>>>>>>>>>>>> that null constraint violations should throw NPEs. Food
>>>> for
>>>>>>>>>>>
>>>>>>>>>>> thought.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>>>>>>>>>>>>
>>>>>>>>>>>> garydgregory@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>>>>>>>>>
>>>>>>>>>>> ebourg@apache.org>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
>>>>>>>>>>>>>>>>>>>> + throw new
>>>>> IllegalArgumentException("Parameter
>>>>>> '"
>>>>>>>>>>>
>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume something is
>>>> very
>>>>>>>> wrong
>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site, somewhere
>>> on
>>>>> the
>>>>>>>>>>>
>>>>>>>>>>> code
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> path.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the call
>>>> site
>>>>>>>>>>>
>>>>>>>>>>> (which
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> be a bug of course).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
>>> it's
>>>>>> hard to
>>>>>>>>>>>>
>>>>>>>>>>>> find
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> examples.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Emmanuel Bourg
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>>> 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
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>>>>> http://github.com/britter
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>>> http://github.com/britter
>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> 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
>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Gary Gregory <ga...@gmail.com>.
It feels to me that this misrepresents the ideas expressed here, or at
least mine ;) I am neither indifferent or favor NPE. I favor IAE, so
does that mean I am nor "most people". If a person make these kinds of
statement, we might as well VOTE or argue-discuss some more...!
Gary
On Sep 1, 2013, at 10:46, Benedikt Ritter <br...@apache.org> wrote:
> Look's like most people are either indifferent or favor NPE. So, do we
> change this for [CSV]? The important thing is to give users an expressive
> message.
>
> Benedikt
>
>
>
> 2013/8/30 Gary Gregory <ga...@gmail.com>
>
>> Surprisingly, a lot. At work, we have a lot of frameworky/plugin-type of
>> code where we run operations on collections of things and we do not want
>> "expected" errors to torpedo the whole processing flow, so we do catch
>> things like IAE and ISE. We do try to avoid catching Exception if we can
>> help it.
>>
>> Gary
>>
>>
>> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com> wrote:
>>
>>> How often do you really want to catch these?
>>>
>>> Matt
>>>
>>>
>>> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@gmail.com
>>>> wrote:
>>>
>>>> Another perspective to think about is whether you want to write code
>>> like:
>>>>
>>>> try {
>>>> // la-di-da
>>>> } catch (NullPointerException e) {
>>>> // garbage in!
>>>> }
>>>>
>>>> or:
>>>>
>>>> try {
>>>> // doo-wap-doo-wap
>>>> } catch (IllegalArugumentException e) {
>>>> // garbage in!
>>>> }
>>>>
>>>> Catching NPE just smells funny to me.
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> The fact that NPE is documented in Bloch is quite important.
>>>>>
>>>>> Whatever we do choose, we should make sure to document all th reasons
>>>>> (pros and cons) somewhere other than just the mailing list!
>>>>>
>>>>> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
>>>>>> The discussion for [lang], none of whose participants have weighed
>> in
>>>>> here,
>>>>>> took place in late 2009 (so perhaps a little longer ago than I
>>> thought)
>>>>> and
>>>>>> is archived at [1]. IMO Paul B. makes some pretty compelling
>>> arguments
>>>>> in
>>>>>> [2].
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
>>>>>> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>>> The JDK Javadoc says of NPE:
>>>>>>>
>>>>>>> * Applications should throw instances of this class to indicate
>>>>>>> * other illegal uses of the <code>null</code> object.
>>>>>>>
>>>>>>> and of IAE:
>>>>>>>
>>>>>>> * Thrown to indicate that a method has been passed an illegal or
>>>>>>> * inappropriate argument.
>>>>>>>
>>>>>>> That says to me that we should throw IAE here.
>>>>>>>
>>>>>>> The JDK does use NPE for parameter checks, but it also uses IAE,
>> for
>>>>>>> example:
>>>>>>>
>>>>>>> javax.management.monitor.Monitor.addObservedObject
>>>>>>> java.rmi.activation.ActivationDesc.ActivationDesc
>>>>>>> javax.management.relation.RoleList.add
>>>>>>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>>>>>>>
>>>>>>> On 30 August 2013 16:50, Adrian Crum <
>>>>> adrian.crum@sandglass-software.com>
>>>>>>> wrote:
>>>>>>>> I've seen a lot of discussions on NPE versus IAE, and in the end
>>>> they
>>>>> all
>>>>>>>> condense down to what Matt stated here: Those who favor NPE cite
>>> the
>>>>> JDK
>>>>>>>> classes as a pattern to follow, and those who favor IAE say it
>> is
>>> a
>>>>>>> better
>>>>>>>> description of the problem. From my perspective, both are valid
>>>>>>> viewpoints,
>>>>>>>> and a project simply needs to choose one. In the end, the choice
>>> is
>>>>>>> neither
>>>>>>>> "right" nor "wrong" - it is just a choice.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/30/2013 8:07 AM, Matt Benson wrote:
>>>>>>>>>
>>>>>>>>> Let me stir the pot:
>>>>>>>>> At a fundamental level I agree that a required *argument*
>>> should
>>>>>>> throw
>>>>>>>>> an
>>>>>>>>> IllegalArgumentException when null is supplied. However, ISTR
>>> the
>>>>>>>>> decision
>>>>>>>>> to do otherwise in [lang] having been discussed on-list in the
>>>>>>>>> not-so-distant past, and the result of that discussion being
>> that
>>>>> NPE is
>>>>>>>>> usually the result in the core JDK classes. So I wouldn't
>>>>> characterize
>>>>>>>>> the
>>>>>>>>> situation as "[lang] *just happens* to throw NPE." Now, [lang]
>>> is
>>>>> in a
>>>>>>>>> slightly unique situation as its stated mission is to
>> complement
>>>> Java
>>>>>>> SE,
>>>>>>>>> so it could be argued that [lang] is under greater pressure to
>>>>> conform
>>>>>>> for
>>>>>>>>> that reason. But my personal preference, in light of the
>>> standing
>>>>>>>>> decision
>>>>>>>>> with [lang], would be for consistency throughout Commons
>>> components
>>>>>>>>> *despite* the fact that at a purely semantic level I agree with
>>> the
>>>>>>>>> arguments in favor of IllegalArgumentException.
>>>>>>>>>
>>>>>>>>> To summarize, +1 for NullPointerException from me.
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
>>>> britter@apache.org
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 2013/8/30 sebb <se...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> On 30 August 2013 15:19, Benedikt Ritter <britter@apache.org
>>>
>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I've removed the generics in r1518974, thanks for spotting
>>> that
>>>>> sebb.
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding the exception to throw I'm indifferent. The
>>> important
>>>>> thing
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>>> fail early.
>>>>>>>>>>> ... and with a helpful message.
>>>>>>>>>>>
>>>>>>>>>>>> I personally thing that NPE should be reserved for signaling
>>>> that
>>>>>>> some
>>>>>>>>>>>
>>>>>>>>>>> code
>>>>>>>>>>>>
>>>>>>>>>>>> tried to invoke a method on a null reference.
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>>> In our case null is illegal because we know that some code
>>> later
>>>>> on
>>>>>>>>>>
>>>>>>>>>> would
>>>>>>>>>>>>
>>>>>>>>>>>> break if we accept a null reference. So
>> IllegalStateException
>>>>> makes
>>>>>>>>>>>
>>>>>>>>>>> sense.
>>>>>>>>>>>
>>>>>>>>>>> s/IllegalStateException /IllegalArgumentException/
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>> Sorry, I meant IAE of corse.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Imaging having a method that accepts an int and only
>> positive
>>>> ints
>>>>>>> are
>>>>>>>>>>>> valid. You would throw an IllegalArgumentException if a
>>> negative
>>>>> int
>>>>>>> is
>>>>>>>>>>>> passed to that method and not a NegativeIntegerException (or
>>>> what
>>>>>>>>>>
>>>>>>>>>> ever).
>>>>>>>>>>>>
>>>>>>>>>>>> But James has a point. If [LANG] uses NPE maybe we should
>>> stick
>>>> to
>>>>>>>>>>
>>>>>>>>>> this.
>>>>>>>>>>>
>>>>>>>>>>> I don't think we have to do the same as LANG, so long as the
>>>>> Javadoc
>>>>>>> is
>>>>>>>>>>> clear.
>>>>>>>>>>>
>>>>>>>>>>>> Feel free to change it. I'll leave it for now since there
>>>> doesn't
>>>>>>> seem
>>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>>> be consensus?!
>>>>>>>>>>>
>>>>>>>>>>> Unless there are other reasons than "LANG happens to use
>> NPE" I
>>>>> think
>>>>>>>>>>> we should stick with IAE, as it more clearly indicates the
>> the
>>>>> problem
>>>>>>>>>>> is not within the method throwing it.
>>>>>>>>>>>
>>>>>>>>>>> The problem with using NPE to flag parameter errors is that
>> it
>>>>>>>>>>> confuses the user as to the likely cause.
>>>>>>>>>>>
>>>>>>>>>>> Leave NPEs to the runtime system.
>>>>>>>>>> agreed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Benedikt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> Well, the problem with using NPE is that we as Java
>>> developers
>>>>> have
>>>>>>>>>>>>> learned through the years that NPE typically is an "oh
>> crap"
>>>>>>>>>>>>> situation, where something is terribly wrong (we hate
>> seeing
>>>>> those).
>>>>>>>>>>>>> Thus, our users may have knee-jerk reactions and not even
>>> know
>>>> to
>>>>>>>>>>>>> inspect the message for the real cause. IAE is less
>>> alarming,
>>>>> IMHO.
>>>>>>>>>>>>> Just my $0.02, but we've been doing it that way for a long
>>> time
>>>>> in
>>>>>>>>>>>>> [lang], so be it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AFAIK "accidental" NPEs don't have a message associated
>> with
>>>>> them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So provided that the assertion generates the NPE with a
>>>> suitable
>>>>>>>>>>>>>> message (e.g.as currently done for the IAE) then it
>>> *should*
>>>> be
>>>>>>>>>>>>>> possible for the end user to distinguish the two cases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am slightly in favour of retaining IAE as the cause is
>>>> obvious
>>>>>>>>>>
>>>>>>>>>> with
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> needing to look at the NPE message.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ==
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Horrible hack: - if you want to use NPE, you could wrap an
>>> IAE
>>>>> in
>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>> NPE:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> npe = new NPE(msg);
>>>>>>>>>>>>>> npe.initCause(new IAE(msg));
>>>>>>>>>>>>>> throw npe;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or vice-vera, of course!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure that gains anything, but it does make the stack
>>> trace
>>>>> look
>>>>>>>>>>>>>> more impressive!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 30 August 2013 13:42, James Carman <
>>>>> james@carmanconsulting.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
>>> know
>>>>> that
>>>>>>>>>>>
>>>>>>>>>>> I've
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> necessarily agreed with that, but at some point a
>> decision
>>>> was
>>>>>>> made
>>>>>>>>>>>>>>> that null constraint violations should throw NPEs. Food
>>> for
>>>>>>>>>>
>>>>>>>>>> thought.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>>>>>>>>>>>
>>>>>>>>>>> garydgregory@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>>>>>>>>
>>>>>>>>>> ebourg@apache.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> + if (parameter == null) {
>>>>>>>>>>>>>>>>>>> + throw new
>>>> IllegalArgumentException("Parameter
>>>>> '"
>>>>>>>>>>
>>>>>>>>>> +
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> parameterName + "' must not be null!");
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>>>>>>> + }
>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>>>>>>>>>>>>>>>> Not always IMO. When I see an NPE I assume something is
>>> very
>>>>>>> wrong
>>>>>>>>>>>
>>>>>>>>>>> and
>>>>>>>>>>>>>
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it could be a bug in the impl OR a call site, somewhere
>> on
>>>> the
>>>>>>>>>>
>>>>>>>>>> code
>>>>>>>>>>>>>
>>>>>>>>>>>>> path.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With an IAE, I know for sure it's a problem in the call
>>> site
>>>>>>>>>>
>>>>>>>>>> (which
>>>>>>>>>>>>>
>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> be a bug of course).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
>> it's
>>>>> hard to
>>>>>>>>>>>
>>>>>>>>>>> find
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> examples.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Emmanuel Bourg
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>> 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
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>>>> http://github.com/britter
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>> http://github.com/britter
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> 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
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Benedikt Ritter <br...@apache.org>.
Look's like most people are either indifferent or favor NPE. So, do we
change this for [CSV]? The important thing is to give users an expressive
message.
Benedikt
2013/8/30 Gary Gregory <ga...@gmail.com>
> Surprisingly, a lot. At work, we have a lot of frameworky/plugin-type of
> code where we run operations on collections of things and we do not want
> "expected" errors to torpedo the whole processing flow, so we do catch
> things like IAE and ISE. We do try to avoid catching Exception if we can
> help it.
>
> Gary
>
>
> On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com> wrote:
>
> > How often do you really want to catch these?
> >
> > Matt
> >
> >
> > On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@gmail.com
> > >wrote:
> >
> > > Another perspective to think about is whether you want to write code
> > like:
> > >
> > > try {
> > > // la-di-da
> > > } catch (NullPointerException e) {
> > > // garbage in!
> > > }
> > >
> > > or:
> > >
> > > try {
> > > // doo-wap-doo-wap
> > > } catch (IllegalArugumentException e) {
> > > // garbage in!
> > > }
> > >
> > > Catching NPE just smells funny to me.
> > >
> > > Gary
> > >
> > >
> > >
> > > On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
> > >
> > > > The fact that NPE is documented in Bloch is quite important.
> > > >
> > > > Whatever we do choose, we should make sure to document all th reasons
> > > > (pros and cons) somewhere other than just the mailing list!
> > > >
> > > > On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
> > > > > The discussion for [lang], none of whose participants have weighed
> in
> > > > here,
> > > > > took place in late 2009 (so perhaps a little longer ago than I
> > thought)
> > > > and
> > > > > is archived at [1]. IMO Paul B. makes some pretty compelling
> > arguments
> > > > in
> > > > > [2].
> > > > >
> > > > > Matt
> > > > >
> > > > > [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> > > > > [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> > > > >
> > > > >
> > > > > On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
> > > > >
> > > > >> The JDK Javadoc says of NPE:
> > > > >>
> > > > >> * Applications should throw instances of this class to indicate
> > > > >> * other illegal uses of the <code>null</code> object.
> > > > >>
> > > > >> and of IAE:
> > > > >>
> > > > >> * Thrown to indicate that a method has been passed an illegal or
> > > > >> * inappropriate argument.
> > > > >>
> > > > >> That says to me that we should throw IAE here.
> > > > >>
> > > > >> The JDK does use NPE for parameter checks, but it also uses IAE,
> for
> > > > >> example:
> > > > >>
> > > > >> javax.management.monitor.Monitor.addObservedObject
> > > > >> java.rmi.activation.ActivationDesc.ActivationDesc
> > > > >> javax.management.relation.RoleList.add
> > > > >> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> > > > >>
> > > > >> On 30 August 2013 16:50, Adrian Crum <
> > > > adrian.crum@sandglass-software.com>
> > > > >> wrote:
> > > > >> > I've seen a lot of discussions on NPE versus IAE, and in the end
> > > they
> > > > all
> > > > >> > condense down to what Matt stated here: Those who favor NPE cite
> > the
> > > > JDK
> > > > >> > classes as a pattern to follow, and those who favor IAE say it
> is
> > a
> > > > >> better
> > > > >> > description of the problem. From my perspective, both are valid
> > > > >> viewpoints,
> > > > >> > and a project simply needs to choose one. In the end, the choice
> > is
> > > > >> neither
> > > > >> > "right" nor "wrong" - it is just a choice.
> > > > >> >
> > > > >> > -Adrian
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On 8/30/2013 8:07 AM, Matt Benson wrote:
> > > > >> >>
> > > > >> >> Let me stir the pot:
> > > > >> >> At a fundamental level I agree that a required *argument*
> > should
> > > > >> throw
> > > > >> >> an
> > > > >> >> IllegalArgumentException when null is supplied. However, ISTR
> > the
> > > > >> >> decision
> > > > >> >> to do otherwise in [lang] having been discussed on-list in the
> > > > >> >> not-so-distant past, and the result of that discussion being
> that
> > > > NPE is
> > > > >> >> usually the result in the core JDK classes. So I wouldn't
> > > > characterize
> > > > >> >> the
> > > > >> >> situation as "[lang] *just happens* to throw NPE." Now, [lang]
> > is
> > > > in a
> > > > >> >> slightly unique situation as its stated mission is to
> complement
> > > Java
> > > > >> SE,
> > > > >> >> so it could be argued that [lang] is under greater pressure to
> > > > conform
> > > > >> for
> > > > >> >> that reason. But my personal preference, in light of the
> > standing
> > > > >> >> decision
> > > > >> >> with [lang], would be for consistency throughout Commons
> > components
> > > > >> >> *despite* the fact that at a purely semantic level I agree with
> > the
> > > > >> >> arguments in favor of IllegalArgumentException.
> > > > >> >>
> > > > >> >> To summarize, +1 for NullPointerException from me.
> > > > >> >>
> > > > >> >> Matt
> > > > >> >>
> > > > >> >>
> > > > >> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
> > > britter@apache.org
> > > > >
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >>> 2013/8/30 sebb <se...@gmail.com>
> > > > >> >>>
> > > > >> >>>> On 30 August 2013 15:19, Benedikt Ritter <britter@apache.org
> >
> > > > wrote:
> > > > >> >>>>>
> > > > >> >>>>> I've removed the generics in r1518974, thanks for spotting
> > that
> > > > sebb.
> > > > >> >>>>>
> > > > >> >>>>> Regarding the exception to throw I'm indifferent. The
> > important
> > > > thing
> > > > >> >>>
> > > > >> >>> is
> > > > >> >>>>
> > > > >> >>>> to
> > > > >> >>>>>
> > > > >> >>>>> fail early.
> > > > >> >>>>>
> > > > >> >>>> ... and with a helpful message.
> > > > >> >>>>
> > > > >> >>>>> I personally thing that NPE should be reserved for signaling
> > > that
> > > > >> some
> > > > >> >>>>
> > > > >> >>>> code
> > > > >> >>>>>
> > > > >> >>>>> tried to invoke a method on a null reference.
> > > > >> >>>>
> > > > >> >>>> +1
> > > > >> >>>>
> > > > >> >>>>> In our case null is illegal because we know that some code
> > later
> > > > on
> > > > >> >>>
> > > > >> >>> would
> > > > >> >>>>>
> > > > >> >>>>> break if we accept a null reference. So
> IllegalStateException
> > > > makes
> > > > >> >>>>
> > > > >> >>>> sense.
> > > > >> >>>>
> > > > >> >>>> s/IllegalStateException /IllegalArgumentException/
> > > > >> >>>>
> > > > >> >>>> +1
> > > > >> >>>>
> > > > >> >>> Sorry, I meant IAE of corse.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>>> Imaging having a method that accepts an int and only
> positive
> > > ints
> > > > >> are
> > > > >> >>>>> valid. You would throw an IllegalArgumentException if a
> > negative
> > > > int
> > > > >> is
> > > > >> >>>>> passed to that method and not a NegativeIntegerException (or
> > > what
> > > > >> >>>
> > > > >> >>> ever).
> > > > >> >>>>>
> > > > >> >>>>> But James has a point. If [LANG] uses NPE maybe we should
> > stick
> > > to
> > > > >> >>>
> > > > >> >>> this.
> > > > >> >>>>
> > > > >> >>>> I don't think we have to do the same as LANG, so long as the
> > > > Javadoc
> > > > >> is
> > > > >> >>>> clear.
> > > > >> >>>>
> > > > >> >>>>> Feel free to change it. I'll leave it for now since there
> > > doesn't
> > > > >> seem
> > > > >> >>>
> > > > >> >>> to
> > > > >> >>>>>
> > > > >> >>>>> be consensus?!
> > > > >> >>>>
> > > > >> >>>> Unless there are other reasons than "LANG happens to use
> NPE" I
> > > > think
> > > > >> >>>> we should stick with IAE, as it more clearly indicates the
> the
> > > > problem
> > > > >> >>>> is not within the method throwing it.
> > > > >> >>>>
> > > > >> >>>> The problem with using NPE to flag parameter errors is that
> it
> > > > >> >>>> confuses the user as to the likely cause.
> > > > >> >>>>
> > > > >> >>>> Leave NPEs to the runtime system.
> > > > >> >>>>
> > > > >> >>> agreed.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>>> Benedikt
> > > > >> >>>>>
> > > > >> >>>>>
> > > > >> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> > > > >> >>>>>
> > > > >> >>>>>> Well, the problem with using NPE is that we as Java
> > developers
> > > > have
> > > > >> >>>>>> learned through the years that NPE typically is an "oh
> crap"
> > > > >> >>>>>> situation, where something is terribly wrong (we hate
> seeing
> > > > those).
> > > > >> >>>>>> Thus, our users may have knee-jerk reactions and not even
> > know
> > > to
> > > > >> >>>>>> inspect the message for the real cause. IAE is less
> > alarming,
> > > > IMHO.
> > > > >> >>>>>> Just my $0.02, but we've been doing it that way for a long
> > time
> > > > in
> > > > >> >>>>>> [lang], so be it.
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
> > > wrote:
> > > > >> >>>>>>>
> > > > >> >>>>>>> AFAIK "accidental" NPEs don't have a message associated
> with
> > > > them.
> > > > >> >>>>>>>
> > > > >> >>>>>>> So provided that the assertion generates the NPE with a
> > > suitable
> > > > >> >>>>>>> message (e.g.as currently done for the IAE) then it
> > *should*
> > > be
> > > > >> >>>>>>> possible for the end user to distinguish the two cases.
> > > > >> >>>>>>>
> > > > >> >>>>>>> I am slightly in favour of retaining IAE as the cause is
> > > obvious
> > > > >> >>>
> > > > >> >>> with
> > > > >> >>>>>>>
> > > > >> >>>>>>> needing to look at the NPE message.
> > > > >> >>>>>>>
> > > > >> >>>>>>> ==
> > > > >> >>>>>>>
> > > > >> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an
> > IAE
> > > > in
> > > > >> >>>
> > > > >> >>> the
> > > > >> >>>>>>
> > > > >> >>>>>> NPE:
> > > > >> >>>>>>>
> > > > >> >>>>>>> npe = new NPE(msg);
> > > > >> >>>>>>> npe.initCause(new IAE(msg));
> > > > >> >>>>>>> throw npe;
> > > > >> >>>>>>>
> > > > >> >>>>>>> Or vice-vera, of course!
> > > > >> >>>>>>>
> > > > >> >>>>>>> Not sure that gains anything, but it does make the stack
> > trace
> > > > look
> > > > >> >>>>>>> more impressive!
> > > > >> >>>>>>>
> > > > >> >>>>>>> On 30 August 2013 13:42, James Carman <
> > > > james@carmanconsulting.com>
> > > > >> >>>>>>
> > > > >> >>>>>> wrote:
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
> > know
> > > > that
> > > > >> >>>>
> > > > >> >>>> I've
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> necessarily agreed with that, but at some point a
> decision
> > > was
> > > > >> made
> > > > >> >>>>>>>> that null constraint violations should throw NPEs. Food
> > for
> > > > >> >>>
> > > > >> >>> thought.
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> > > > >> >>>>
> > > > >> >>>> garydgregory@gmail.com>
> > > > >> >>>>>>
> > > > >> >>>>>> wrote:
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> > > > >> >>>
> > > > >> >>> ebourg@apache.org>
> > > > >> >>>>>>
> > > > >> >>>>>> wrote:
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>> + if (parameter == null) {
> > > > >> >>>>>>>>>>>> + throw new
> > > IllegalArgumentException("Parameter
> > > > '"
> > > > >> >>>
> > > > >> >>> +
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> parameterName + "' must not be null!");
> > > > >> >>>>>>>>>>>>
> > > > >> >>>>>>>>>>>> + }
> > > > >> >>>>>>>>>>>> + }
> > > > >> >>>>>>>>>>>> +}
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>> Not always IMO. When I see an NPE I assume something is
> > very
> > > > >> wrong
> > > > >> >>>>
> > > > >> >>>> and
> > > > >> >>>>>>
> > > > >> >>>>>> that
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere
> on
> > > the
> > > > >> >>>
> > > > >> >>> code
> > > > >> >>>>>>
> > > > >> >>>>>> path.
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> With an IAE, I know for sure it's a problem in the call
> > site
> > > > >> >>>
> > > > >> >>> (which
> > > > >> >>>>>>
> > > > >> >>>>>> could
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> be a bug of course).
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so
> it's
> > > > hard to
> > > > >> >>>>
> > > > >> >>>> find
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> examples.
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> Gary
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>>> Emmanuel Bourg
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>
> > > > >> >>>>
> > > > ---------------------------------------------------------------------
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>> To unsubscribe, e-mail:
> > dev-unsubscribe@commons.apache.org
> > > > >> >>>>>>>>>> For additional commands, e-mail:
> > > dev-help@commons.apache.org
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>>
> > > > >> >>>>>>>>>
> > > > >> >>>>>>>>> --
> > > > >> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > >> >>>>>>>>> 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
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>
> > > > >> >>>
> > > > ---------------------------------------------------------------------
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > > > >> >>>>>>>> For additional commands, e-mail:
> > dev-help@commons.apache.org
> > > > >> >>>>>>>>
> > > > >> >>>>>>>
> > > > >> >>>
> > > > ---------------------------------------------------------------------
> > > > >> >>>>>>>
> > > > >> >>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > > > >> >>>>>>> For additional commands, e-mail:
> > dev-help@commons.apache.org
> > > > >> >>>>>>>
> > > > >> >>>>>>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> >>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>
> > > > >> >>>>> --
> > > > >> >>>>> http://people.apache.org/~britter/
> > > > >> >>>>> http://www.systemoutprintln.de/
> > > > >> >>>>> http://twitter.com/BenediktRitter
> > > > >> >>>>> http://github.com/britter
> > > > >> >>>>
> > > > >> >>>>
> > > > ---------------------------------------------------------------------
> > > > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>
> > > > >> >>> --
> > > > >> >>> http://people.apache.org/~britter/
> > > > >> >>> http://www.systemoutprintln.de/
> > > > >> >>> http://twitter.com/BenediktRitter
> > > > >> >>> http://github.com/britter
> > > > >> >>>
> > > > >> >
> > > > >> >
> > > > >> >
> > > ---------------------------------------------------------------------
> > > > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >> >
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > > >>
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > 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
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Gary Gregory <ga...@gmail.com>.
Surprisingly, a lot. At work, we have a lot of frameworky/plugin-type of
code where we run operations on collections of things and we do not want
"expected" errors to torpedo the whole processing flow, so we do catch
things like IAE and ISE. We do try to avoid catching Exception if we can
help it.
Gary
On Fri, Aug 30, 2013 at 2:32 PM, Matt Benson <gu...@gmail.com> wrote:
> How often do you really want to catch these?
>
> Matt
>
>
> On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgregory@gmail.com
> >wrote:
>
> > Another perspective to think about is whether you want to write code
> like:
> >
> > try {
> > // la-di-da
> > } catch (NullPointerException e) {
> > // garbage in!
> > }
> >
> > or:
> >
> > try {
> > // doo-wap-doo-wap
> > } catch (IllegalArugumentException e) {
> > // garbage in!
> > }
> >
> > Catching NPE just smells funny to me.
> >
> > Gary
> >
> >
> >
> > On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
> >
> > > The fact that NPE is documented in Bloch is quite important.
> > >
> > > Whatever we do choose, we should make sure to document all th reasons
> > > (pros and cons) somewhere other than just the mailing list!
> > >
> > > On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
> > > > The discussion for [lang], none of whose participants have weighed in
> > > here,
> > > > took place in late 2009 (so perhaps a little longer ago than I
> thought)
> > > and
> > > > is archived at [1]. IMO Paul B. makes some pretty compelling
> arguments
> > > in
> > > > [2].
> > > >
> > > > Matt
> > > >
> > > > [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> > > > [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> > > >
> > > >
> > > > On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
> > > >
> > > >> The JDK Javadoc says of NPE:
> > > >>
> > > >> * Applications should throw instances of this class to indicate
> > > >> * other illegal uses of the <code>null</code> object.
> > > >>
> > > >> and of IAE:
> > > >>
> > > >> * Thrown to indicate that a method has been passed an illegal or
> > > >> * inappropriate argument.
> > > >>
> > > >> That says to me that we should throw IAE here.
> > > >>
> > > >> The JDK does use NPE for parameter checks, but it also uses IAE, for
> > > >> example:
> > > >>
> > > >> javax.management.monitor.Monitor.addObservedObject
> > > >> java.rmi.activation.ActivationDesc.ActivationDesc
> > > >> javax.management.relation.RoleList.add
> > > >> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> > > >>
> > > >> On 30 August 2013 16:50, Adrian Crum <
> > > adrian.crum@sandglass-software.com>
> > > >> wrote:
> > > >> > I've seen a lot of discussions on NPE versus IAE, and in the end
> > they
> > > all
> > > >> > condense down to what Matt stated here: Those who favor NPE cite
> the
> > > JDK
> > > >> > classes as a pattern to follow, and those who favor IAE say it is
> a
> > > >> better
> > > >> > description of the problem. From my perspective, both are valid
> > > >> viewpoints,
> > > >> > and a project simply needs to choose one. In the end, the choice
> is
> > > >> neither
> > > >> > "right" nor "wrong" - it is just a choice.
> > > >> >
> > > >> > -Adrian
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 8/30/2013 8:07 AM, Matt Benson wrote:
> > > >> >>
> > > >> >> Let me stir the pot:
> > > >> >> At a fundamental level I agree that a required *argument*
> should
> > > >> throw
> > > >> >> an
> > > >> >> IllegalArgumentException when null is supplied. However, ISTR
> the
> > > >> >> decision
> > > >> >> to do otherwise in [lang] having been discussed on-list in the
> > > >> >> not-so-distant past, and the result of that discussion being that
> > > NPE is
> > > >> >> usually the result in the core JDK classes. So I wouldn't
> > > characterize
> > > >> >> the
> > > >> >> situation as "[lang] *just happens* to throw NPE." Now, [lang]
> is
> > > in a
> > > >> >> slightly unique situation as its stated mission is to complement
> > Java
> > > >> SE,
> > > >> >> so it could be argued that [lang] is under greater pressure to
> > > conform
> > > >> for
> > > >> >> that reason. But my personal preference, in light of the
> standing
> > > >> >> decision
> > > >> >> with [lang], would be for consistency throughout Commons
> components
> > > >> >> *despite* the fact that at a purely semantic level I agree with
> the
> > > >> >> arguments in favor of IllegalArgumentException.
> > > >> >>
> > > >> >> To summarize, +1 for NullPointerException from me.
> > > >> >>
> > > >> >> Matt
> > > >> >>
> > > >> >>
> > > >> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
> > britter@apache.org
> > > >
> > > >> >> wrote:
> > > >> >>
> > > >> >>> 2013/8/30 sebb <se...@gmail.com>
> > > >> >>>
> > > >> >>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org>
> > > wrote:
> > > >> >>>>>
> > > >> >>>>> I've removed the generics in r1518974, thanks for spotting
> that
> > > sebb.
> > > >> >>>>>
> > > >> >>>>> Regarding the exception to throw I'm indifferent. The
> important
> > > thing
> > > >> >>>
> > > >> >>> is
> > > >> >>>>
> > > >> >>>> to
> > > >> >>>>>
> > > >> >>>>> fail early.
> > > >> >>>>>
> > > >> >>>> ... and with a helpful message.
> > > >> >>>>
> > > >> >>>>> I personally thing that NPE should be reserved for signaling
> > that
> > > >> some
> > > >> >>>>
> > > >> >>>> code
> > > >> >>>>>
> > > >> >>>>> tried to invoke a method on a null reference.
> > > >> >>>>
> > > >> >>>> +1
> > > >> >>>>
> > > >> >>>>> In our case null is illegal because we know that some code
> later
> > > on
> > > >> >>>
> > > >> >>> would
> > > >> >>>>>
> > > >> >>>>> break if we accept a null reference. So IllegalStateException
> > > makes
> > > >> >>>>
> > > >> >>>> sense.
> > > >> >>>>
> > > >> >>>> s/IllegalStateException /IllegalArgumentException/
> > > >> >>>>
> > > >> >>>> +1
> > > >> >>>>
> > > >> >>> Sorry, I meant IAE of corse.
> > > >> >>>
> > > >> >>>
> > > >> >>>>> Imaging having a method that accepts an int and only positive
> > ints
> > > >> are
> > > >> >>>>> valid. You would throw an IllegalArgumentException if a
> negative
> > > int
> > > >> is
> > > >> >>>>> passed to that method and not a NegativeIntegerException (or
> > what
> > > >> >>>
> > > >> >>> ever).
> > > >> >>>>>
> > > >> >>>>> But James has a point. If [LANG] uses NPE maybe we should
> stick
> > to
> > > >> >>>
> > > >> >>> this.
> > > >> >>>>
> > > >> >>>> I don't think we have to do the same as LANG, so long as the
> > > Javadoc
> > > >> is
> > > >> >>>> clear.
> > > >> >>>>
> > > >> >>>>> Feel free to change it. I'll leave it for now since there
> > doesn't
> > > >> seem
> > > >> >>>
> > > >> >>> to
> > > >> >>>>>
> > > >> >>>>> be consensus?!
> > > >> >>>>
> > > >> >>>> Unless there are other reasons than "LANG happens to use NPE" I
> > > think
> > > >> >>>> we should stick with IAE, as it more clearly indicates the the
> > > problem
> > > >> >>>> is not within the method throwing it.
> > > >> >>>>
> > > >> >>>> The problem with using NPE to flag parameter errors is that it
> > > >> >>>> confuses the user as to the likely cause.
> > > >> >>>>
> > > >> >>>> Leave NPEs to the runtime system.
> > > >> >>>>
> > > >> >>> agreed.
> > > >> >>>
> > > >> >>>
> > > >> >>>>> Benedikt
> > > >> >>>>>
> > > >> >>>>>
> > > >> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> > > >> >>>>>
> > > >> >>>>>> Well, the problem with using NPE is that we as Java
> developers
> > > have
> > > >> >>>>>> learned through the years that NPE typically is an "oh crap"
> > > >> >>>>>> situation, where something is terribly wrong (we hate seeing
> > > those).
> > > >> >>>>>> Thus, our users may have knee-jerk reactions and not even
> know
> > to
> > > >> >>>>>> inspect the message for the real cause. IAE is less
> alarming,
> > > IMHO.
> > > >> >>>>>> Just my $0.02, but we've been doing it that way for a long
> time
> > > in
> > > >> >>>>>> [lang], so be it.
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
> > wrote:
> > > >> >>>>>>>
> > > >> >>>>>>> AFAIK "accidental" NPEs don't have a message associated with
> > > them.
> > > >> >>>>>>>
> > > >> >>>>>>> So provided that the assertion generates the NPE with a
> > suitable
> > > >> >>>>>>> message (e.g.as currently done for the IAE) then it
> *should*
> > be
> > > >> >>>>>>> possible for the end user to distinguish the two cases.
> > > >> >>>>>>>
> > > >> >>>>>>> I am slightly in favour of retaining IAE as the cause is
> > obvious
> > > >> >>>
> > > >> >>> with
> > > >> >>>>>>>
> > > >> >>>>>>> needing to look at the NPE message.
> > > >> >>>>>>>
> > > >> >>>>>>> ==
> > > >> >>>>>>>
> > > >> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an
> IAE
> > > in
> > > >> >>>
> > > >> >>> the
> > > >> >>>>>>
> > > >> >>>>>> NPE:
> > > >> >>>>>>>
> > > >> >>>>>>> npe = new NPE(msg);
> > > >> >>>>>>> npe.initCause(new IAE(msg));
> > > >> >>>>>>> throw npe;
> > > >> >>>>>>>
> > > >> >>>>>>> Or vice-vera, of course!
> > > >> >>>>>>>
> > > >> >>>>>>> Not sure that gains anything, but it does make the stack
> trace
> > > look
> > > >> >>>>>>> more impressive!
> > > >> >>>>>>>
> > > >> >>>>>>> On 30 August 2013 13:42, James Carman <
> > > james@carmanconsulting.com>
> > > >> >>>>>>
> > > >> >>>>>> wrote:
> > > >> >>>>>>>>
> > > >> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't
> know
> > > that
> > > >> >>>>
> > > >> >>>> I've
> > > >> >>>>>>>>
> > > >> >>>>>>>> necessarily agreed with that, but at some point a decision
> > was
> > > >> made
> > > >> >>>>>>>> that null constraint violations should throw NPEs. Food
> for
> > > >> >>>
> > > >> >>> thought.
> > > >> >>>>>>>>
> > > >> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> > > >> >>>>
> > > >> >>>> garydgregory@gmail.com>
> > > >> >>>>>>
> > > >> >>>>>> wrote:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> > > >> >>>
> > > >> >>> ebourg@apache.org>
> > > >> >>>>>>
> > > >> >>>>>> wrote:
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> + if (parameter == null) {
> > > >> >>>>>>>>>>>> + throw new
> > IllegalArgumentException("Parameter
> > > '"
> > > >> >>>
> > > >> >>> +
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>> parameterName + "' must not be null!");
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> + }
> > > >> >>>>>>>>>>>> + }
> > > >> >>>>>>>>>>>> +}
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>> Not always IMO. When I see an NPE I assume something is
> very
> > > >> wrong
> > > >> >>>>
> > > >> >>>> and
> > > >> >>>>>>
> > > >> >>>>>> that
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere on
> > the
> > > >> >>>
> > > >> >>> code
> > > >> >>>>>>
> > > >> >>>>>> path.
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> With an IAE, I know for sure it's a problem in the call
> site
> > > >> >>>
> > > >> >>> (which
> > > >> >>>>>>
> > > >> >>>>>> could
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> be a bug of course).
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's
> > > hard to
> > > >> >>>>
> > > >> >>>> find
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> examples.
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> Gary
> > > >> >>>>>>>>>
> > > >> >>>>>>>>>
> > > >> >>>>>>>>>> Emmanuel Bourg
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >>>>
> > > ---------------------------------------------------------------------
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > > >> >>>>>>>>>> For additional commands, e-mail:
> > dev-help@commons.apache.org
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> --
> > > >> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > >> >>>>>>>>> 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
> > > >> >>>>>>>>
> > > >> >>>>>>>>
> > > >> >>>
> > > ---------------------------------------------------------------------
> > > >> >>>>>>>>
> > > >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> >>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> > > >> >>>>>>>>
> > > >> >>>>>>>
> > > >> >>>
> > > ---------------------------------------------------------------------
> > > >> >>>>>>>
> > > >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> >>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> > > >> >>>>>>>
> > > >> >>>>>>
> > > >>
> ---------------------------------------------------------------------
> > > >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>
> > > >> >>>>> --
> > > >> >>>>> http://people.apache.org/~britter/
> > > >> >>>>> http://www.systemoutprintln.de/
> > > >> >>>>> http://twitter.com/BenediktRitter
> > > >> >>>>> http://github.com/britter
> > > >> >>>>
> > > >> >>>>
> > > ---------------------------------------------------------------------
> > > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > > >> >>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>> --
> > > >> >>> http://people.apache.org/~britter/
> > > >> >>> http://www.systemoutprintln.de/
> > > >> >>> http://twitter.com/BenediktRitter
> > > >> >>> http://github.com/britter
> > > >> >>>
> > > >> >
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > > >> >
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
How often do you really want to catch these?
Matt
On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <ga...@gmail.com>wrote:
> Another perspective to think about is whether you want to write code like:
>
> try {
> // la-di-da
> } catch (NullPointerException e) {
> // garbage in!
> }
>
> or:
>
> try {
> // doo-wap-doo-wap
> } catch (IllegalArugumentException e) {
> // garbage in!
> }
>
> Catching NPE just smells funny to me.
>
> Gary
>
>
>
> On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
>
> > The fact that NPE is documented in Bloch is quite important.
> >
> > Whatever we do choose, we should make sure to document all th reasons
> > (pros and cons) somewhere other than just the mailing list!
> >
> > On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
> > > The discussion for [lang], none of whose participants have weighed in
> > here,
> > > took place in late 2009 (so perhaps a little longer ago than I thought)
> > and
> > > is archived at [1]. IMO Paul B. makes some pretty compelling arguments
> > in
> > > [2].
> > >
> > > Matt
> > >
> > > [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> > > [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> > >
> > >
> > > On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
> > >
> > >> The JDK Javadoc says of NPE:
> > >>
> > >> * Applications should throw instances of this class to indicate
> > >> * other illegal uses of the <code>null</code> object.
> > >>
> > >> and of IAE:
> > >>
> > >> * Thrown to indicate that a method has been passed an illegal or
> > >> * inappropriate argument.
> > >>
> > >> That says to me that we should throw IAE here.
> > >>
> > >> The JDK does use NPE for parameter checks, but it also uses IAE, for
> > >> example:
> > >>
> > >> javax.management.monitor.Monitor.addObservedObject
> > >> java.rmi.activation.ActivationDesc.ActivationDesc
> > >> javax.management.relation.RoleList.add
> > >> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> > >>
> > >> On 30 August 2013 16:50, Adrian Crum <
> > adrian.crum@sandglass-software.com>
> > >> wrote:
> > >> > I've seen a lot of discussions on NPE versus IAE, and in the end
> they
> > all
> > >> > condense down to what Matt stated here: Those who favor NPE cite the
> > JDK
> > >> > classes as a pattern to follow, and those who favor IAE say it is a
> > >> better
> > >> > description of the problem. From my perspective, both are valid
> > >> viewpoints,
> > >> > and a project simply needs to choose one. In the end, the choice is
> > >> neither
> > >> > "right" nor "wrong" - it is just a choice.
> > >> >
> > >> > -Adrian
> > >> >
> > >> >
> > >> >
> > >> > On 8/30/2013 8:07 AM, Matt Benson wrote:
> > >> >>
> > >> >> Let me stir the pot:
> > >> >> At a fundamental level I agree that a required *argument* should
> > >> throw
> > >> >> an
> > >> >> IllegalArgumentException when null is supplied. However, ISTR the
> > >> >> decision
> > >> >> to do otherwise in [lang] having been discussed on-list in the
> > >> >> not-so-distant past, and the result of that discussion being that
> > NPE is
> > >> >> usually the result in the core JDK classes. So I wouldn't
> > characterize
> > >> >> the
> > >> >> situation as "[lang] *just happens* to throw NPE." Now, [lang] is
> > in a
> > >> >> slightly unique situation as its stated mission is to complement
> Java
> > >> SE,
> > >> >> so it could be argued that [lang] is under greater pressure to
> > conform
> > >> for
> > >> >> that reason. But my personal preference, in light of the standing
> > >> >> decision
> > >> >> with [lang], would be for consistency throughout Commons components
> > >> >> *despite* the fact that at a purely semantic level I agree with the
> > >> >> arguments in favor of IllegalArgumentException.
> > >> >>
> > >> >> To summarize, +1 for NullPointerException from me.
> > >> >>
> > >> >> Matt
> > >> >>
> > >> >>
> > >> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <
> britter@apache.org
> > >
> > >> >> wrote:
> > >> >>
> > >> >>> 2013/8/30 sebb <se...@gmail.com>
> > >> >>>
> > >> >>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org>
> > wrote:
> > >> >>>>>
> > >> >>>>> I've removed the generics in r1518974, thanks for spotting that
> > sebb.
> > >> >>>>>
> > >> >>>>> Regarding the exception to throw I'm indifferent. The important
> > thing
> > >> >>>
> > >> >>> is
> > >> >>>>
> > >> >>>> to
> > >> >>>>>
> > >> >>>>> fail early.
> > >> >>>>>
> > >> >>>> ... and with a helpful message.
> > >> >>>>
> > >> >>>>> I personally thing that NPE should be reserved for signaling
> that
> > >> some
> > >> >>>>
> > >> >>>> code
> > >> >>>>>
> > >> >>>>> tried to invoke a method on a null reference.
> > >> >>>>
> > >> >>>> +1
> > >> >>>>
> > >> >>>>> In our case null is illegal because we know that some code later
> > on
> > >> >>>
> > >> >>> would
> > >> >>>>>
> > >> >>>>> break if we accept a null reference. So IllegalStateException
> > makes
> > >> >>>>
> > >> >>>> sense.
> > >> >>>>
> > >> >>>> s/IllegalStateException /IllegalArgumentException/
> > >> >>>>
> > >> >>>> +1
> > >> >>>>
> > >> >>> Sorry, I meant IAE of corse.
> > >> >>>
> > >> >>>
> > >> >>>>> Imaging having a method that accepts an int and only positive
> ints
> > >> are
> > >> >>>>> valid. You would throw an IllegalArgumentException if a negative
> > int
> > >> is
> > >> >>>>> passed to that method and not a NegativeIntegerException (or
> what
> > >> >>>
> > >> >>> ever).
> > >> >>>>>
> > >> >>>>> But James has a point. If [LANG] uses NPE maybe we should stick
> to
> > >> >>>
> > >> >>> this.
> > >> >>>>
> > >> >>>> I don't think we have to do the same as LANG, so long as the
> > Javadoc
> > >> is
> > >> >>>> clear.
> > >> >>>>
> > >> >>>>> Feel free to change it. I'll leave it for now since there
> doesn't
> > >> seem
> > >> >>>
> > >> >>> to
> > >> >>>>>
> > >> >>>>> be consensus?!
> > >> >>>>
> > >> >>>> Unless there are other reasons than "LANG happens to use NPE" I
> > think
> > >> >>>> we should stick with IAE, as it more clearly indicates the the
> > problem
> > >> >>>> is not within the method throwing it.
> > >> >>>>
> > >> >>>> The problem with using NPE to flag parameter errors is that it
> > >> >>>> confuses the user as to the likely cause.
> > >> >>>>
> > >> >>>> Leave NPEs to the runtime system.
> > >> >>>>
> > >> >>> agreed.
> > >> >>>
> > >> >>>
> > >> >>>>> Benedikt
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> > >> >>>>>
> > >> >>>>>> Well, the problem with using NPE is that we as Java developers
> > have
> > >> >>>>>> learned through the years that NPE typically is an "oh crap"
> > >> >>>>>> situation, where something is terribly wrong (we hate seeing
> > those).
> > >> >>>>>> Thus, our users may have knee-jerk reactions and not even know
> to
> > >> >>>>>> inspect the message for the real cause. IAE is less alarming,
> > IMHO.
> > >> >>>>>> Just my $0.02, but we've been doing it that way for a long time
> > in
> > >> >>>>>> [lang], so be it.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com>
> wrote:
> > >> >>>>>>>
> > >> >>>>>>> AFAIK "accidental" NPEs don't have a message associated with
> > them.
> > >> >>>>>>>
> > >> >>>>>>> So provided that the assertion generates the NPE with a
> suitable
> > >> >>>>>>> message (e.g.as currently done for the IAE) then it *should*
> be
> > >> >>>>>>> possible for the end user to distinguish the two cases.
> > >> >>>>>>>
> > >> >>>>>>> I am slightly in favour of retaining IAE as the cause is
> obvious
> > >> >>>
> > >> >>> with
> > >> >>>>>>>
> > >> >>>>>>> needing to look at the NPE message.
> > >> >>>>>>>
> > >> >>>>>>> ==
> > >> >>>>>>>
> > >> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE
> > in
> > >> >>>
> > >> >>> the
> > >> >>>>>>
> > >> >>>>>> NPE:
> > >> >>>>>>>
> > >> >>>>>>> npe = new NPE(msg);
> > >> >>>>>>> npe.initCause(new IAE(msg));
> > >> >>>>>>> throw npe;
> > >> >>>>>>>
> > >> >>>>>>> Or vice-vera, of course!
> > >> >>>>>>>
> > >> >>>>>>> Not sure that gains anything, but it does make the stack trace
> > look
> > >> >>>>>>> more impressive!
> > >> >>>>>>>
> > >> >>>>>>> On 30 August 2013 13:42, James Carman <
> > james@carmanconsulting.com>
> > >> >>>>>>
> > >> >>>>>> wrote:
> > >> >>>>>>>>
> > >> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know
> > that
> > >> >>>>
> > >> >>>> I've
> > >> >>>>>>>>
> > >> >>>>>>>> necessarily agreed with that, but at some point a decision
> was
> > >> made
> > >> >>>>>>>> that null constraint violations should throw NPEs. Food for
> > >> >>>
> > >> >>> thought.
> > >> >>>>>>>>
> > >> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> > >> >>>>
> > >> >>>> garydgregory@gmail.com>
> > >> >>>>>>
> > >> >>>>>> wrote:
> > >> >>>>>>>>>
> > >> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> > >> >>>
> > >> >>> ebourg@apache.org>
> > >> >>>>>>
> > >> >>>>>> wrote:
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> + if (parameter == null) {
> > >> >>>>>>>>>>>> + throw new
> IllegalArgumentException("Parameter
> > '"
> > >> >>>
> > >> >>> +
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> parameterName + "' must not be null!");
> > >> >>>>>>>>>>>>
> > >> >>>>>>>>>>>> + }
> > >> >>>>>>>>>>>> + }
> > >> >>>>>>>>>>>> +}
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> > >> >>>>>>>>>>
> > >> >>>>>>>>> Not always IMO. When I see an NPE I assume something is very
> > >> wrong
> > >> >>>>
> > >> >>>> and
> > >> >>>>>>
> > >> >>>>>> that
> > >> >>>>>>>>>
> > >> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere on
> the
> > >> >>>
> > >> >>> code
> > >> >>>>>>
> > >> >>>>>> path.
> > >> >>>>>>>>>
> > >> >>>>>>>>> With an IAE, I know for sure it's a problem in the call site
> > >> >>>
> > >> >>> (which
> > >> >>>>>>
> > >> >>>>>> could
> > >> >>>>>>>>>
> > >> >>>>>>>>> be a bug of course).
> > >> >>>>>>>>>
> > >> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's
> > hard to
> > >> >>>>
> > >> >>>> find
> > >> >>>>>>>>>
> > >> >>>>>>>>> examples.
> > >> >>>>>>>>>
> > >> >>>>>>>>> Gary
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>> Emmanuel Bourg
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>
> > ---------------------------------------------------------------------
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >>>>>>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> --
> > >> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > >> >>>>>>>>> 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
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>
> > ---------------------------------------------------------------------
> > >> >>>>>>>>
> > >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>>>>>>>
> > >> >>>>>>>
> > >> >>>
> > ---------------------------------------------------------------------
> > >> >>>>>>>
> > >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>>>>>>
> > >> >>>>>>
> > >> ---------------------------------------------------------------------
> > >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>> --
> > >> >>>>> http://people.apache.org/~britter/
> > >> >>>>> http://www.systemoutprintln.de/
> > >> >>>>> http://twitter.com/BenediktRitter
> > >> >>>>> http://github.com/britter
> > >> >>>>
> > >> >>>>
> > ---------------------------------------------------------------------
> > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>> --
> > >> >>> http://people.apache.org/~britter/
> > >> >>> http://www.systemoutprintln.de/
> > >> >>> http://twitter.com/BenediktRitter
> > >> >>> http://github.com/britter
> > >> >>>
> > >> >
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Gary Gregory <ga...@gmail.com>.
Another perspective to think about is whether you want to write code like:
try {
// la-di-da
} catch (NullPointerException e) {
// garbage in!
}
or:
try {
// doo-wap-doo-wap
} catch (IllegalArugumentException e) {
// garbage in!
}
Catching NPE just smells funny to me.
Gary
On Fri, Aug 30, 2013 at 1:06 PM, sebb <se...@gmail.com> wrote:
> The fact that NPE is documented in Bloch is quite important.
>
> Whatever we do choose, we should make sure to document all th reasons
> (pros and cons) somewhere other than just the mailing list!
>
> On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
> > The discussion for [lang], none of whose participants have weighed in
> here,
> > took place in late 2009 (so perhaps a little longer ago than I thought)
> and
> > is archived at [1]. IMO Paul B. makes some pretty compelling arguments
> in
> > [2].
> >
> > Matt
> >
> > [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> > [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
> >
> >
> > On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
> >
> >> The JDK Javadoc says of NPE:
> >>
> >> * Applications should throw instances of this class to indicate
> >> * other illegal uses of the <code>null</code> object.
> >>
> >> and of IAE:
> >>
> >> * Thrown to indicate that a method has been passed an illegal or
> >> * inappropriate argument.
> >>
> >> That says to me that we should throw IAE here.
> >>
> >> The JDK does use NPE for parameter checks, but it also uses IAE, for
> >> example:
> >>
> >> javax.management.monitor.Monitor.addObservedObject
> >> java.rmi.activation.ActivationDesc.ActivationDesc
> >> javax.management.relation.RoleList.add
> >> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
> >>
> >> On 30 August 2013 16:50, Adrian Crum <
> adrian.crum@sandglass-software.com>
> >> wrote:
> >> > I've seen a lot of discussions on NPE versus IAE, and in the end they
> all
> >> > condense down to what Matt stated here: Those who favor NPE cite the
> JDK
> >> > classes as a pattern to follow, and those who favor IAE say it is a
> >> better
> >> > description of the problem. From my perspective, both are valid
> >> viewpoints,
> >> > and a project simply needs to choose one. In the end, the choice is
> >> neither
> >> > "right" nor "wrong" - it is just a choice.
> >> >
> >> > -Adrian
> >> >
> >> >
> >> >
> >> > On 8/30/2013 8:07 AM, Matt Benson wrote:
> >> >>
> >> >> Let me stir the pot:
> >> >> At a fundamental level I agree that a required *argument* should
> >> throw
> >> >> an
> >> >> IllegalArgumentException when null is supplied. However, ISTR the
> >> >> decision
> >> >> to do otherwise in [lang] having been discussed on-list in the
> >> >> not-so-distant past, and the result of that discussion being that
> NPE is
> >> >> usually the result in the core JDK classes. So I wouldn't
> characterize
> >> >> the
> >> >> situation as "[lang] *just happens* to throw NPE." Now, [lang] is
> in a
> >> >> slightly unique situation as its stated mission is to complement Java
> >> SE,
> >> >> so it could be argued that [lang] is under greater pressure to
> conform
> >> for
> >> >> that reason. But my personal preference, in light of the standing
> >> >> decision
> >> >> with [lang], would be for consistency throughout Commons components
> >> >> *despite* the fact that at a purely semantic level I agree with the
> >> >> arguments in favor of IllegalArgumentException.
> >> >>
> >> >> To summarize, +1 for NullPointerException from me.
> >> >>
> >> >> Matt
> >> >>
> >> >>
> >> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <britter@apache.org
> >
> >> >> wrote:
> >> >>
> >> >>> 2013/8/30 sebb <se...@gmail.com>
> >> >>>
> >> >>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org>
> wrote:
> >> >>>>>
> >> >>>>> I've removed the generics in r1518974, thanks for spotting that
> sebb.
> >> >>>>>
> >> >>>>> Regarding the exception to throw I'm indifferent. The important
> thing
> >> >>>
> >> >>> is
> >> >>>>
> >> >>>> to
> >> >>>>>
> >> >>>>> fail early.
> >> >>>>>
> >> >>>> ... and with a helpful message.
> >> >>>>
> >> >>>>> I personally thing that NPE should be reserved for signaling that
> >> some
> >> >>>>
> >> >>>> code
> >> >>>>>
> >> >>>>> tried to invoke a method on a null reference.
> >> >>>>
> >> >>>> +1
> >> >>>>
> >> >>>>> In our case null is illegal because we know that some code later
> on
> >> >>>
> >> >>> would
> >> >>>>>
> >> >>>>> break if we accept a null reference. So IllegalStateException
> makes
> >> >>>>
> >> >>>> sense.
> >> >>>>
> >> >>>> s/IllegalStateException /IllegalArgumentException/
> >> >>>>
> >> >>>> +1
> >> >>>>
> >> >>> Sorry, I meant IAE of corse.
> >> >>>
> >> >>>
> >> >>>>> Imaging having a method that accepts an int and only positive ints
> >> are
> >> >>>>> valid. You would throw an IllegalArgumentException if a negative
> int
> >> is
> >> >>>>> passed to that method and not a NegativeIntegerException (or what
> >> >>>
> >> >>> ever).
> >> >>>>>
> >> >>>>> But James has a point. If [LANG] uses NPE maybe we should stick to
> >> >>>
> >> >>> this.
> >> >>>>
> >> >>>> I don't think we have to do the same as LANG, so long as the
> Javadoc
> >> is
> >> >>>> clear.
> >> >>>>
> >> >>>>> Feel free to change it. I'll leave it for now since there doesn't
> >> seem
> >> >>>
> >> >>> to
> >> >>>>>
> >> >>>>> be consensus?!
> >> >>>>
> >> >>>> Unless there are other reasons than "LANG happens to use NPE" I
> think
> >> >>>> we should stick with IAE, as it more clearly indicates the the
> problem
> >> >>>> is not within the method throwing it.
> >> >>>>
> >> >>>> The problem with using NPE to flag parameter errors is that it
> >> >>>> confuses the user as to the likely cause.
> >> >>>>
> >> >>>> Leave NPEs to the runtime system.
> >> >>>>
> >> >>> agreed.
> >> >>>
> >> >>>
> >> >>>>> Benedikt
> >> >>>>>
> >> >>>>>
> >> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >> >>>>>
> >> >>>>>> Well, the problem with using NPE is that we as Java developers
> have
> >> >>>>>> learned through the years that NPE typically is an "oh crap"
> >> >>>>>> situation, where something is terribly wrong (we hate seeing
> those).
> >> >>>>>> Thus, our users may have knee-jerk reactions and not even know to
> >> >>>>>> inspect the message for the real cause. IAE is less alarming,
> IMHO.
> >> >>>>>> Just my $0.02, but we've been doing it that way for a long time
> in
> >> >>>>>> [lang], so be it.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> >> >>>>>>>
> >> >>>>>>> AFAIK "accidental" NPEs don't have a message associated with
> them.
> >> >>>>>>>
> >> >>>>>>> So provided that the assertion generates the NPE with a suitable
> >> >>>>>>> message (e.g.as currently done for the IAE) then it *should* be
> >> >>>>>>> possible for the end user to distinguish the two cases.
> >> >>>>>>>
> >> >>>>>>> I am slightly in favour of retaining IAE as the cause is obvious
> >> >>>
> >> >>> with
> >> >>>>>>>
> >> >>>>>>> needing to look at the NPE message.
> >> >>>>>>>
> >> >>>>>>> ==
> >> >>>>>>>
> >> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE
> in
> >> >>>
> >> >>> the
> >> >>>>>>
> >> >>>>>> NPE:
> >> >>>>>>>
> >> >>>>>>> npe = new NPE(msg);
> >> >>>>>>> npe.initCause(new IAE(msg));
> >> >>>>>>> throw npe;
> >> >>>>>>>
> >> >>>>>>> Or vice-vera, of course!
> >> >>>>>>>
> >> >>>>>>> Not sure that gains anything, but it does make the stack trace
> look
> >> >>>>>>> more impressive!
> >> >>>>>>>
> >> >>>>>>> On 30 August 2013 13:42, James Carman <
> james@carmanconsulting.com>
> >> >>>>>>
> >> >>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know
> that
> >> >>>>
> >> >>>> I've
> >> >>>>>>>>
> >> >>>>>>>> necessarily agreed with that, but at some point a decision was
> >> made
> >> >>>>>>>> that null constraint violations should throw NPEs. Food for
> >> >>>
> >> >>> thought.
> >> >>>>>>>>
> >> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> >> >>>>
> >> >>>> garydgregory@gmail.com>
> >> >>>>>>
> >> >>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >> >>>
> >> >>> ebourg@apache.org>
> >> >>>>>>
> >> >>>>>> wrote:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> + if (parameter == null) {
> >> >>>>>>>>>>>> + throw new IllegalArgumentException("Parameter
> '"
> >> >>>
> >> >>> +
> >> >>>>>>>>>>
> >> >>>>>>>>>> parameterName + "' must not be null!");
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> + }
> >> >>>>>>>>>>>> + }
> >> >>>>>>>>>>>> +}
> >> >>>>>>>>>>
> >> >>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> >> >>>>>>>>>>
> >> >>>>>>>>> Not always IMO. When I see an NPE I assume something is very
> >> wrong
> >> >>>>
> >> >>>> and
> >> >>>>>>
> >> >>>>>> that
> >> >>>>>>>>>
> >> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere on the
> >> >>>
> >> >>> code
> >> >>>>>>
> >> >>>>>> path.
> >> >>>>>>>>>
> >> >>>>>>>>> With an IAE, I know for sure it's a problem in the call site
> >> >>>
> >> >>> (which
> >> >>>>>>
> >> >>>>>> could
> >> >>>>>>>>>
> >> >>>>>>>>> be a bug of course).
> >> >>>>>>>>>
> >> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's
> hard to
> >> >>>>
> >> >>>> find
> >> >>>>>>>>>
> >> >>>>>>>>> examples.
> >> >>>>>>>>>
> >> >>>>>>>>> Gary
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> Emmanuel Bourg
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>>>>
> >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> --
> >> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>>>>>>>> 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
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>>>>>>
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>>>>>
> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> http://people.apache.org/~britter/
> >> >>>>> http://www.systemoutprintln.de/
> >> >>>>> http://twitter.com/BenediktRitter
> >> >>>>> http://github.com/britter
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>> --
> >> >>> http://people.apache.org/~britter/
> >> >>> http://www.systemoutprintln.de/
> >> >>> http://twitter.com/BenediktRitter
> >> >>> http://github.com/britter
> >> >>>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by sebb <se...@gmail.com>.
The fact that NPE is documented in Bloch is quite important.
Whatever we do choose, we should make sure to document all th reasons
(pros and cons) somewhere other than just the mailing list!
On 30 August 2013 17:30, Matt Benson <gu...@gmail.com> wrote:
> The discussion for [lang], none of whose participants have weighed in here,
> took place in late 2009 (so perhaps a little longer ago than I thought) and
> is archived at [1]. IMO Paul B. makes some pretty compelling arguments in
> [2].
>
> Matt
>
> [1] http://markmail.org/thread/7gw7xzrc3c3ul74c
> [2] http://markmail.org/message/wmc4jh4pmhjjtxdf
>
>
> On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
>
>> The JDK Javadoc says of NPE:
>>
>> * Applications should throw instances of this class to indicate
>> * other illegal uses of the <code>null</code> object.
>>
>> and of IAE:
>>
>> * Thrown to indicate that a method has been passed an illegal or
>> * inappropriate argument.
>>
>> That says to me that we should throw IAE here.
>>
>> The JDK does use NPE for parameter checks, but it also uses IAE, for
>> example:
>>
>> javax.management.monitor.Monitor.addObservedObject
>> java.rmi.activation.ActivationDesc.ActivationDesc
>> javax.management.relation.RoleList.add
>> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>>
>> On 30 August 2013 16:50, Adrian Crum <ad...@sandglass-software.com>
>> wrote:
>> > I've seen a lot of discussions on NPE versus IAE, and in the end they all
>> > condense down to what Matt stated here: Those who favor NPE cite the JDK
>> > classes as a pattern to follow, and those who favor IAE say it is a
>> better
>> > description of the problem. From my perspective, both are valid
>> viewpoints,
>> > and a project simply needs to choose one. In the end, the choice is
>> neither
>> > "right" nor "wrong" - it is just a choice.
>> >
>> > -Adrian
>> >
>> >
>> >
>> > On 8/30/2013 8:07 AM, Matt Benson wrote:
>> >>
>> >> Let me stir the pot:
>> >> At a fundamental level I agree that a required *argument* should
>> throw
>> >> an
>> >> IllegalArgumentException when null is supplied. However, ISTR the
>> >> decision
>> >> to do otherwise in [lang] having been discussed on-list in the
>> >> not-so-distant past, and the result of that discussion being that NPE is
>> >> usually the result in the core JDK classes. So I wouldn't characterize
>> >> the
>> >> situation as "[lang] *just happens* to throw NPE." Now, [lang] is in a
>> >> slightly unique situation as its stated mission is to complement Java
>> SE,
>> >> so it could be argued that [lang] is under greater pressure to conform
>> for
>> >> that reason. But my personal preference, in light of the standing
>> >> decision
>> >> with [lang], would be for consistency throughout Commons components
>> >> *despite* the fact that at a purely semantic level I agree with the
>> >> arguments in favor of IllegalArgumentException.
>> >>
>> >> To summarize, +1 for NullPointerException from me.
>> >>
>> >> Matt
>> >>
>> >>
>> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <br...@apache.org>
>> >> wrote:
>> >>
>> >>> 2013/8/30 sebb <se...@gmail.com>
>> >>>
>> >>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
>> >>>>>
>> >>>>> I've removed the generics in r1518974, thanks for spotting that sebb.
>> >>>>>
>> >>>>> Regarding the exception to throw I'm indifferent. The important thing
>> >>>
>> >>> is
>> >>>>
>> >>>> to
>> >>>>>
>> >>>>> fail early.
>> >>>>>
>> >>>> ... and with a helpful message.
>> >>>>
>> >>>>> I personally thing that NPE should be reserved for signaling that
>> some
>> >>>>
>> >>>> code
>> >>>>>
>> >>>>> tried to invoke a method on a null reference.
>> >>>>
>> >>>> +1
>> >>>>
>> >>>>> In our case null is illegal because we know that some code later on
>> >>>
>> >>> would
>> >>>>>
>> >>>>> break if we accept a null reference. So IllegalStateException makes
>> >>>>
>> >>>> sense.
>> >>>>
>> >>>> s/IllegalStateException /IllegalArgumentException/
>> >>>>
>> >>>> +1
>> >>>>
>> >>> Sorry, I meant IAE of corse.
>> >>>
>> >>>
>> >>>>> Imaging having a method that accepts an int and only positive ints
>> are
>> >>>>> valid. You would throw an IllegalArgumentException if a negative int
>> is
>> >>>>> passed to that method and not a NegativeIntegerException (or what
>> >>>
>> >>> ever).
>> >>>>>
>> >>>>> But James has a point. If [LANG] uses NPE maybe we should stick to
>> >>>
>> >>> this.
>> >>>>
>> >>>> I don't think we have to do the same as LANG, so long as the Javadoc
>> is
>> >>>> clear.
>> >>>>
>> >>>>> Feel free to change it. I'll leave it for now since there doesn't
>> seem
>> >>>
>> >>> to
>> >>>>>
>> >>>>> be consensus?!
>> >>>>
>> >>>> Unless there are other reasons than "LANG happens to use NPE" I think
>> >>>> we should stick with IAE, as it more clearly indicates the the problem
>> >>>> is not within the method throwing it.
>> >>>>
>> >>>> The problem with using NPE to flag parameter errors is that it
>> >>>> confuses the user as to the likely cause.
>> >>>>
>> >>>> Leave NPEs to the runtime system.
>> >>>>
>> >>> agreed.
>> >>>
>> >>>
>> >>>>> Benedikt
>> >>>>>
>> >>>>>
>> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>> >>>>>
>> >>>>>> Well, the problem with using NPE is that we as Java developers have
>> >>>>>> learned through the years that NPE typically is an "oh crap"
>> >>>>>> situation, where something is terribly wrong (we hate seeing those).
>> >>>>>> Thus, our users may have knee-jerk reactions and not even know to
>> >>>>>> inspect the message for the real cause. IAE is less alarming, IMHO.
>> >>>>>> Just my $0.02, but we've been doing it that way for a long time in
>> >>>>>> [lang], so be it.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>> AFAIK "accidental" NPEs don't have a message associated with them.
>> >>>>>>>
>> >>>>>>> So provided that the assertion generates the NPE with a suitable
>> >>>>>>> message (e.g.as currently done for the IAE) then it *should* be
>> >>>>>>> possible for the end user to distinguish the two cases.
>> >>>>>>>
>> >>>>>>> I am slightly in favour of retaining IAE as the cause is obvious
>> >>>
>> >>> with
>> >>>>>>>
>> >>>>>>> needing to look at the NPE message.
>> >>>>>>>
>> >>>>>>> ==
>> >>>>>>>
>> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE in
>> >>>
>> >>> the
>> >>>>>>
>> >>>>>> NPE:
>> >>>>>>>
>> >>>>>>> npe = new NPE(msg);
>> >>>>>>> npe.initCause(new IAE(msg));
>> >>>>>>> throw npe;
>> >>>>>>>
>> >>>>>>> Or vice-vera, of course!
>> >>>>>>>
>> >>>>>>> Not sure that gains anything, but it does make the stack trace look
>> >>>>>>> more impressive!
>> >>>>>>>
>> >>>>>>> On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
>> >>>>>>
>> >>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know that
>> >>>>
>> >>>> I've
>> >>>>>>>>
>> >>>>>>>> necessarily agreed with that, but at some point a decision was
>> made
>> >>>>>>>> that null constraint violations should throw NPEs. Food for
>> >>>
>> >>> thought.
>> >>>>>>>>
>> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>> >>>>
>> >>>> garydgregory@gmail.com>
>> >>>>>>
>> >>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> >>>
>> >>> ebourg@apache.org>
>> >>>>>>
>> >>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> + if (parameter == null) {
>> >>>>>>>>>>>> + throw new IllegalArgumentException("Parameter '"
>> >>>
>> >>> +
>> >>>>>>>>>>
>> >>>>>>>>>> parameterName + "' must not be null!");
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> + }
>> >>>>>>>>>>>> + }
>> >>>>>>>>>>>> +}
>> >>>>>>>>>>
>> >>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>> >>>>>>>>>>
>> >>>>>>>>> Not always IMO. When I see an NPE I assume something is very
>> wrong
>> >>>>
>> >>>> and
>> >>>>>>
>> >>>>>> that
>> >>>>>>>>>
>> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere on the
>> >>>
>> >>> code
>> >>>>>>
>> >>>>>> path.
>> >>>>>>>>>
>> >>>>>>>>> With an IAE, I know for sure it's a problem in the call site
>> >>>
>> >>> (which
>> >>>>>>
>> >>>>>> could
>> >>>>>>>>>
>> >>>>>>>>> be a bug of course).
>> >>>>>>>>>
>> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's hard to
>> >>>>
>> >>>> find
>> >>>>>>>>>
>> >>>>>>>>> examples.
>> >>>>>>>>>
>> >>>>>>>>> Gary
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> Emmanuel Bourg
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>>>>
>> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>>>>>>>> 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
>> >>>>>>>>
>> >>>>>>>>
>> >>> ---------------------------------------------------------------------
>> >>>>>>>>
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>>
>> >>>>>>>
>> >>> ---------------------------------------------------------------------
>> >>>>>>>
>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> --
>> >>>>> http://people.apache.org/~britter/
>> >>>>> http://www.systemoutprintln.de/
>> >>>>> http://twitter.com/BenediktRitter
>> >>>>> http://github.com/britter
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>> http://people.apache.org/~britter/
>> >>> http://www.systemoutprintln.de/
>> >>> http://twitter.com/BenediktRitter
>> >>> http://github.com/britter
>> >>>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
The discussion for [lang], none of whose participants have weighed in here,
took place in late 2009 (so perhaps a little longer ago than I thought) and
is archived at [1]. IMO Paul B. makes some pretty compelling arguments in
[2].
Matt
[1] http://markmail.org/thread/7gw7xzrc3c3ul74c
[2] http://markmail.org/message/wmc4jh4pmhjjtxdf
On Fri, Aug 30, 2013 at 11:13 AM, sebb <se...@gmail.com> wrote:
> The JDK Javadoc says of NPE:
>
> * Applications should throw instances of this class to indicate
> * other illegal uses of the <code>null</code> object.
>
> and of IAE:
>
> * Thrown to indicate that a method has been passed an illegal or
> * inappropriate argument.
>
> That says to me that we should throw IAE here.
>
> The JDK does use NPE for parameter checks, but it also uses IAE, for
> example:
>
> javax.management.monitor.Monitor.addObservedObject
> java.rmi.activation.ActivationDesc.ActivationDesc
> javax.management.relation.RoleList.add
> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
>
> On 30 August 2013 16:50, Adrian Crum <ad...@sandglass-software.com>
> wrote:
> > I've seen a lot of discussions on NPE versus IAE, and in the end they all
> > condense down to what Matt stated here: Those who favor NPE cite the JDK
> > classes as a pattern to follow, and those who favor IAE say it is a
> better
> > description of the problem. From my perspective, both are valid
> viewpoints,
> > and a project simply needs to choose one. In the end, the choice is
> neither
> > "right" nor "wrong" - it is just a choice.
> >
> > -Adrian
> >
> >
> >
> > On 8/30/2013 8:07 AM, Matt Benson wrote:
> >>
> >> Let me stir the pot:
> >> At a fundamental level I agree that a required *argument* should
> throw
> >> an
> >> IllegalArgumentException when null is supplied. However, ISTR the
> >> decision
> >> to do otherwise in [lang] having been discussed on-list in the
> >> not-so-distant past, and the result of that discussion being that NPE is
> >> usually the result in the core JDK classes. So I wouldn't characterize
> >> the
> >> situation as "[lang] *just happens* to throw NPE." Now, [lang] is in a
> >> slightly unique situation as its stated mission is to complement Java
> SE,
> >> so it could be argued that [lang] is under greater pressure to conform
> for
> >> that reason. But my personal preference, in light of the standing
> >> decision
> >> with [lang], would be for consistency throughout Commons components
> >> *despite* the fact that at a purely semantic level I agree with the
> >> arguments in favor of IllegalArgumentException.
> >>
> >> To summarize, +1 for NullPointerException from me.
> >>
> >> Matt
> >>
> >>
> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <br...@apache.org>
> >> wrote:
> >>
> >>> 2013/8/30 sebb <se...@gmail.com>
> >>>
> >>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
> >>>>>
> >>>>> I've removed the generics in r1518974, thanks for spotting that sebb.
> >>>>>
> >>>>> Regarding the exception to throw I'm indifferent. The important thing
> >>>
> >>> is
> >>>>
> >>>> to
> >>>>>
> >>>>> fail early.
> >>>>>
> >>>> ... and with a helpful message.
> >>>>
> >>>>> I personally thing that NPE should be reserved for signaling that
> some
> >>>>
> >>>> code
> >>>>>
> >>>>> tried to invoke a method on a null reference.
> >>>>
> >>>> +1
> >>>>
> >>>>> In our case null is illegal because we know that some code later on
> >>>
> >>> would
> >>>>>
> >>>>> break if we accept a null reference. So IllegalStateException makes
> >>>>
> >>>> sense.
> >>>>
> >>>> s/IllegalStateException /IllegalArgumentException/
> >>>>
> >>>> +1
> >>>>
> >>> Sorry, I meant IAE of corse.
> >>>
> >>>
> >>>>> Imaging having a method that accepts an int and only positive ints
> are
> >>>>> valid. You would throw an IllegalArgumentException if a negative int
> is
> >>>>> passed to that method and not a NegativeIntegerException (or what
> >>>
> >>> ever).
> >>>>>
> >>>>> But James has a point. If [LANG] uses NPE maybe we should stick to
> >>>
> >>> this.
> >>>>
> >>>> I don't think we have to do the same as LANG, so long as the Javadoc
> is
> >>>> clear.
> >>>>
> >>>>> Feel free to change it. I'll leave it for now since there doesn't
> seem
> >>>
> >>> to
> >>>>>
> >>>>> be consensus?!
> >>>>
> >>>> Unless there are other reasons than "LANG happens to use NPE" I think
> >>>> we should stick with IAE, as it more clearly indicates the the problem
> >>>> is not within the method throwing it.
> >>>>
> >>>> The problem with using NPE to flag parameter errors is that it
> >>>> confuses the user as to the likely cause.
> >>>>
> >>>> Leave NPEs to the runtime system.
> >>>>
> >>> agreed.
> >>>
> >>>
> >>>>> Benedikt
> >>>>>
> >>>>>
> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >>>>>
> >>>>>> Well, the problem with using NPE is that we as Java developers have
> >>>>>> learned through the years that NPE typically is an "oh crap"
> >>>>>> situation, where something is terribly wrong (we hate seeing those).
> >>>>>> Thus, our users may have knee-jerk reactions and not even know to
> >>>>>> inspect the message for the real cause. IAE is less alarming, IMHO.
> >>>>>> Just my $0.02, but we've been doing it that way for a long time in
> >>>>>> [lang], so be it.
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> AFAIK "accidental" NPEs don't have a message associated with them.
> >>>>>>>
> >>>>>>> So provided that the assertion generates the NPE with a suitable
> >>>>>>> message (e.g.as currently done for the IAE) then it *should* be
> >>>>>>> possible for the end user to distinguish the two cases.
> >>>>>>>
> >>>>>>> I am slightly in favour of retaining IAE as the cause is obvious
> >>>
> >>> with
> >>>>>>>
> >>>>>>> needing to look at the NPE message.
> >>>>>>>
> >>>>>>> ==
> >>>>>>>
> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE in
> >>>
> >>> the
> >>>>>>
> >>>>>> NPE:
> >>>>>>>
> >>>>>>> npe = new NPE(msg);
> >>>>>>> npe.initCause(new IAE(msg));
> >>>>>>> throw npe;
> >>>>>>>
> >>>>>>> Or vice-vera, of course!
> >>>>>>>
> >>>>>>> Not sure that gains anything, but it does make the stack trace look
> >>>>>>> more impressive!
> >>>>>>>
> >>>>>>> On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know that
> >>>>
> >>>> I've
> >>>>>>>>
> >>>>>>>> necessarily agreed with that, but at some point a decision was
> made
> >>>>>>>> that null constraint violations should throw NPEs. Food for
> >>>
> >>> thought.
> >>>>>>>>
> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> >>>>
> >>>> garydgregory@gmail.com>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> >>>
> >>> ebourg@apache.org>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> + if (parameter == null) {
> >>>>>>>>>>>> + throw new IllegalArgumentException("Parameter '"
> >>>
> >>> +
> >>>>>>>>>>
> >>>>>>>>>> parameterName + "' must not be null!");
> >>>>>>>>>>>>
> >>>>>>>>>>>> + }
> >>>>>>>>>>>> + }
> >>>>>>>>>>>> +}
> >>>>>>>>>>
> >>>>>>>>>> Isn't a null value supposed to throw a NPE ?
> >>>>>>>>>>
> >>>>>>>>> Not always IMO. When I see an NPE I assume something is very
> wrong
> >>>>
> >>>> and
> >>>>>>
> >>>>>> that
> >>>>>>>>>
> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere on the
> >>>
> >>> code
> >>>>>>
> >>>>>> path.
> >>>>>>>>>
> >>>>>>>>> With an IAE, I know for sure it's a problem in the call site
> >>>
> >>> (which
> >>>>>>
> >>>>>> could
> >>>>>>>>>
> >>>>>>>>> be a bug of course).
> >>>>>>>>>
> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's hard to
> >>>>
> >>>> find
> >>>>>>>>>
> >>>>>>>>> examples.
> >>>>>>>>>
> >>>>>>>>> Gary
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Emmanuel Bourg
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> http://people.apache.org/~britter/
> >>>>> http://www.systemoutprintln.de/
> >>>>> http://twitter.com/BenediktRitter
> >>>>> http://github.com/britter
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>> --
> >>> http://people.apache.org/~britter/
> >>> http://www.systemoutprintln.de/
> >>> http://twitter.com/BenediktRitter
> >>> http://github.com/britter
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by sebb <se...@gmail.com>.
The JDK Javadoc says of NPE:
* Applications should throw instances of this class to indicate
* other illegal uses of the <code>null</code> object.
and of IAE:
* Thrown to indicate that a method has been passed an illegal or
* inappropriate argument.
That says to me that we should throw IAE here.
The JDK does use NPE for parameter checks, but it also uses IAE, for example:
javax.management.monitor.Monitor.addObservedObject
java.rmi.activation.ActivationDesc.ActivationDesc
javax.management.relation.RoleList.add
javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute
On 30 August 2013 16:50, Adrian Crum <ad...@sandglass-software.com> wrote:
> I've seen a lot of discussions on NPE versus IAE, and in the end they all
> condense down to what Matt stated here: Those who favor NPE cite the JDK
> classes as a pattern to follow, and those who favor IAE say it is a better
> description of the problem. From my perspective, both are valid viewpoints,
> and a project simply needs to choose one. In the end, the choice is neither
> "right" nor "wrong" - it is just a choice.
>
> -Adrian
>
>
>
> On 8/30/2013 8:07 AM, Matt Benson wrote:
>>
>> Let me stir the pot:
>> At a fundamental level I agree that a required *argument* should throw
>> an
>> IllegalArgumentException when null is supplied. However, ISTR the
>> decision
>> to do otherwise in [lang] having been discussed on-list in the
>> not-so-distant past, and the result of that discussion being that NPE is
>> usually the result in the core JDK classes. So I wouldn't characterize
>> the
>> situation as "[lang] *just happens* to throw NPE." Now, [lang] is in a
>> slightly unique situation as its stated mission is to complement Java SE,
>> so it could be argued that [lang] is under greater pressure to conform for
>> that reason. But my personal preference, in light of the standing
>> decision
>> with [lang], would be for consistency throughout Commons components
>> *despite* the fact that at a purely semantic level I agree with the
>> arguments in favor of IllegalArgumentException.
>>
>> To summarize, +1 for NullPointerException from me.
>>
>> Matt
>>
>>
>> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <br...@apache.org>
>> wrote:
>>
>>> 2013/8/30 sebb <se...@gmail.com>
>>>
>>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
>>>>>
>>>>> I've removed the generics in r1518974, thanks for spotting that sebb.
>>>>>
>>>>> Regarding the exception to throw I'm indifferent. The important thing
>>>
>>> is
>>>>
>>>> to
>>>>>
>>>>> fail early.
>>>>>
>>>> ... and with a helpful message.
>>>>
>>>>> I personally thing that NPE should be reserved for signaling that some
>>>>
>>>> code
>>>>>
>>>>> tried to invoke a method on a null reference.
>>>>
>>>> +1
>>>>
>>>>> In our case null is illegal because we know that some code later on
>>>
>>> would
>>>>>
>>>>> break if we accept a null reference. So IllegalStateException makes
>>>>
>>>> sense.
>>>>
>>>> s/IllegalStateException /IllegalArgumentException/
>>>>
>>>> +1
>>>>
>>> Sorry, I meant IAE of corse.
>>>
>>>
>>>>> Imaging having a method that accepts an int and only positive ints are
>>>>> valid. You would throw an IllegalArgumentException if a negative int is
>>>>> passed to that method and not a NegativeIntegerException (or what
>>>
>>> ever).
>>>>>
>>>>> But James has a point. If [LANG] uses NPE maybe we should stick to
>>>
>>> this.
>>>>
>>>> I don't think we have to do the same as LANG, so long as the Javadoc is
>>>> clear.
>>>>
>>>>> Feel free to change it. I'll leave it for now since there doesn't seem
>>>
>>> to
>>>>>
>>>>> be consensus?!
>>>>
>>>> Unless there are other reasons than "LANG happens to use NPE" I think
>>>> we should stick with IAE, as it more clearly indicates the the problem
>>>> is not within the method throwing it.
>>>>
>>>> The problem with using NPE to flag parameter errors is that it
>>>> confuses the user as to the likely cause.
>>>>
>>>> Leave NPEs to the runtime system.
>>>>
>>> agreed.
>>>
>>>
>>>>> Benedikt
>>>>>
>>>>>
>>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>>>>>
>>>>>> Well, the problem with using NPE is that we as Java developers have
>>>>>> learned through the years that NPE typically is an "oh crap"
>>>>>> situation, where something is terribly wrong (we hate seeing those).
>>>>>> Thus, our users may have knee-jerk reactions and not even know to
>>>>>> inspect the message for the real cause. IAE is less alarming, IMHO.
>>>>>> Just my $0.02, but we've been doing it that way for a long time in
>>>>>> [lang], so be it.
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>> AFAIK "accidental" NPEs don't have a message associated with them.
>>>>>>>
>>>>>>> So provided that the assertion generates the NPE with a suitable
>>>>>>> message (e.g.as currently done for the IAE) then it *should* be
>>>>>>> possible for the end user to distinguish the two cases.
>>>>>>>
>>>>>>> I am slightly in favour of retaining IAE as the cause is obvious
>>>
>>> with
>>>>>>>
>>>>>>> needing to look at the NPE message.
>>>>>>>
>>>>>>> ==
>>>>>>>
>>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE in
>>>
>>> the
>>>>>>
>>>>>> NPE:
>>>>>>>
>>>>>>> npe = new NPE(msg);
>>>>>>> npe.initCause(new IAE(msg));
>>>>>>> throw npe;
>>>>>>>
>>>>>>> Or vice-vera, of course!
>>>>>>>
>>>>>>> Not sure that gains anything, but it does make the stack trace look
>>>>>>> more impressive!
>>>>>>>
>>>>>>> On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
>>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know that
>>>>
>>>> I've
>>>>>>>>
>>>>>>>> necessarily agreed with that, but at some point a decision was made
>>>>>>>> that null constraint violations should throw NPEs. Food for
>>>
>>> thought.
>>>>>>>>
>>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>>>>
>>>> garydgregory@gmail.com>
>>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>>>
>>> ebourg@apache.org>
>>>>>>
>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> + if (parameter == null) {
>>>>>>>>>>>> + throw new IllegalArgumentException("Parameter '"
>>>
>>> +
>>>>>>>>>>
>>>>>>>>>> parameterName + "' must not be null!");
>>>>>>>>>>>>
>>>>>>>>>>>> + }
>>>>>>>>>>>> + }
>>>>>>>>>>>> +}
>>>>>>>>>>
>>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>>>>>>>>>>
>>>>>>>>> Not always IMO. When I see an NPE I assume something is very wrong
>>>>
>>>> and
>>>>>>
>>>>>> that
>>>>>>>>>
>>>>>>>>> it could be a bug in the impl OR a call site, somewhere on the
>>>
>>> code
>>>>>>
>>>>>> path.
>>>>>>>>>
>>>>>>>>> With an IAE, I know for sure it's a problem in the call site
>>>
>>> (which
>>>>>>
>>>>>> could
>>>>>>>>>
>>>>>>>>> be a bug of course).
>>>>>>>>>
>>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's hard to
>>>>
>>>> find
>>>>>>>>>
>>>>>>>>> examples.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Emmanuel Bourg
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> http://people.apache.org/~britter/
>>>>> http://www.systemoutprintln.de/
>>>>> http://twitter.com/BenediktRitter
>>>>> http://github.com/britter
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [spam] Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Adrian Crum <ad...@sandglass-software.com>.
I've seen a lot of discussions on NPE versus IAE, and in the end they
all condense down to what Matt stated here: Those who favor NPE cite the
JDK classes as a pattern to follow, and those who favor IAE say it is a
better description of the problem. From my perspective, both are valid
viewpoints, and a project simply needs to choose one. In the end, the
choice is neither "right" nor "wrong" - it is just a choice.
-Adrian
On 8/30/2013 8:07 AM, Matt Benson wrote:
> Let me stir the pot:
> At a fundamental level I agree that a required *argument* should throw an
> IllegalArgumentException when null is supplied. However, ISTR the decision
> to do otherwise in [lang] having been discussed on-list in the
> not-so-distant past, and the result of that discussion being that NPE is
> usually the result in the core JDK classes. So I wouldn't characterize the
> situation as "[lang] *just happens* to throw NPE." Now, [lang] is in a
> slightly unique situation as its stated mission is to complement Java SE,
> so it could be argued that [lang] is under greater pressure to conform for
> that reason. But my personal preference, in light of the standing decision
> with [lang], would be for consistency throughout Commons components
> *despite* the fact that at a purely semantic level I agree with the
> arguments in favor of IllegalArgumentException.
>
> To summarize, +1 for NullPointerException from me.
>
> Matt
>
>
> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <br...@apache.org> wrote:
>
>> 2013/8/30 sebb <se...@gmail.com>
>>
>>> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
>>>> I've removed the generics in r1518974, thanks for spotting that sebb.
>>>>
>>>> Regarding the exception to throw I'm indifferent. The important thing
>> is
>>> to
>>>> fail early.
>>>>
>>> ... and with a helpful message.
>>>
>>>> I personally thing that NPE should be reserved for signaling that some
>>> code
>>>> tried to invoke a method on a null reference.
>>> +1
>>>
>>>> In our case null is illegal because we know that some code later on
>> would
>>>> break if we accept a null reference. So IllegalStateException makes
>>> sense.
>>>
>>> s/IllegalStateException /IllegalArgumentException/
>>>
>>> +1
>>>
>> Sorry, I meant IAE of corse.
>>
>>
>>>> Imaging having a method that accepts an int and only positive ints are
>>>> valid. You would throw an IllegalArgumentException if a negative int is
>>>> passed to that method and not a NegativeIntegerException (or what
>> ever).
>>>> But James has a point. If [LANG] uses NPE maybe we should stick to
>> this.
>>> I don't think we have to do the same as LANG, so long as the Javadoc is
>>> clear.
>>>
>>>> Feel free to change it. I'll leave it for now since there doesn't seem
>> to
>>>> be consensus?!
>>> Unless there are other reasons than "LANG happens to use NPE" I think
>>> we should stick with IAE, as it more clearly indicates the the problem
>>> is not within the method throwing it.
>>>
>>> The problem with using NPE to flag parameter errors is that it
>>> confuses the user as to the likely cause.
>>>
>>> Leave NPEs to the runtime system.
>>>
>> agreed.
>>
>>
>>>> Benedikt
>>>>
>>>>
>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>>>>
>>>>> Well, the problem with using NPE is that we as Java developers have
>>>>> learned through the years that NPE typically is an "oh crap"
>>>>> situation, where something is terribly wrong (we hate seeing those).
>>>>> Thus, our users may have knee-jerk reactions and not even know to
>>>>> inspect the message for the real cause. IAE is less alarming, IMHO.
>>>>> Just my $0.02, but we've been doing it that way for a long time in
>>>>> [lang], so be it.
>>>>>
>>>>>
>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
>>>>>> AFAIK "accidental" NPEs don't have a message associated with them.
>>>>>>
>>>>>> So provided that the assertion generates the NPE with a suitable
>>>>>> message (e.g.as currently done for the IAE) then it *should* be
>>>>>> possible for the end user to distinguish the two cases.
>>>>>>
>>>>>> I am slightly in favour of retaining IAE as the cause is obvious
>> with
>>>>>> needing to look at the NPE message.
>>>>>>
>>>>>> ==
>>>>>>
>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE in
>> the
>>>>> NPE:
>>>>>> npe = new NPE(msg);
>>>>>> npe.initCause(new IAE(msg));
>>>>>> throw npe;
>>>>>>
>>>>>> Or vice-vera, of course!
>>>>>>
>>>>>> Not sure that gains anything, but it does make the stack trace look
>>>>>> more impressive!
>>>>>>
>>>>>> On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
>>>>> wrote:
>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know that
>>> I've
>>>>>>> necessarily agreed with that, but at some point a decision was made
>>>>>>> that null constraint violations should throw NPEs. Food for
>> thought.
>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
>>> garydgregory@gmail.com>
>>>>> wrote:
>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
>> ebourg@apache.org>
>>>>> wrote:
>>>>>>>>>>> + if (parameter == null) {
>>>>>>>>>>> + throw new IllegalArgumentException("Parameter '"
>> +
>>>>>>>>> parameterName + "' must not be null!");
>>>>>>>>>>> + }
>>>>>>>>>>> + }
>>>>>>>>>>> +}
>>>>>>>>> Isn't a null value supposed to throw a NPE ?
>>>>>>>>>
>>>>>>>> Not always IMO. When I see an NPE I assume something is very wrong
>>> and
>>>>> that
>>>>>>>> it could be a bug in the impl OR a call site, somewhere on the
>> code
>>>>> path.
>>>>>>>> With an IAE, I know for sure it's a problem in the call site
>> (which
>>>>> could
>>>>>>>> be a bug of course).
>>>>>>>>
>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's hard to
>>> find
>>>>>>>> examples.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>> Emmanuel Bourg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> 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
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Matt Benson <gu...@gmail.com>.
Let me stir the pot:
At a fundamental level I agree that a required *argument* should throw an
IllegalArgumentException when null is supplied. However, ISTR the decision
to do otherwise in [lang] having been discussed on-list in the
not-so-distant past, and the result of that discussion being that NPE is
usually the result in the core JDK classes. So I wouldn't characterize the
situation as "[lang] *just happens* to throw NPE." Now, [lang] is in a
slightly unique situation as its stated mission is to complement Java SE,
so it could be argued that [lang] is under greater pressure to conform for
that reason. But my personal preference, in light of the standing decision
with [lang], would be for consistency throughout Commons components
*despite* the fact that at a purely semantic level I agree with the
arguments in favor of IllegalArgumentException.
To summarize, +1 for NullPointerException from me.
Matt
On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter <br...@apache.org> wrote:
> 2013/8/30 sebb <se...@gmail.com>
>
> > On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
> > > I've removed the generics in r1518974, thanks for spotting that sebb.
> > >
> > > Regarding the exception to throw I'm indifferent. The important thing
> is
> > to
> > > fail early.
> > >
> >
> > ... and with a helpful message.
> >
> > > I personally thing that NPE should be reserved for signaling that some
> > code
> > > tried to invoke a method on a null reference.
> >
> > +1
> >
> > > In our case null is illegal because we know that some code later on
> would
> > > break if we accept a null reference. So IllegalStateException makes
> > sense.
> >
> > s/IllegalStateException /IllegalArgumentException/
> >
> > +1
> >
>
> Sorry, I meant IAE of corse.
>
>
> >
> > > Imaging having a method that accepts an int and only positive ints are
> > > valid. You would throw an IllegalArgumentException if a negative int is
> > > passed to that method and not a NegativeIntegerException (or what
> ever).
> > > But James has a point. If [LANG] uses NPE maybe we should stick to
> this.
> >
> > I don't think we have to do the same as LANG, so long as the Javadoc is
> > clear.
> >
> > > Feel free to change it. I'll leave it for now since there doesn't seem
> to
> > > be consensus?!
> >
> > Unless there are other reasons than "LANG happens to use NPE" I think
> > we should stick with IAE, as it more clearly indicates the the problem
> > is not within the method throwing it.
> >
> > The problem with using NPE to flag parameter errors is that it
> > confuses the user as to the likely cause.
> >
> > Leave NPEs to the runtime system.
> >
>
> agreed.
>
>
> >
> > > Benedikt
> > >
> > >
> > > 2013/8/30 James Carman <ja...@carmanconsulting.com>
> > >
> > >> Well, the problem with using NPE is that we as Java developers have
> > >> learned through the years that NPE typically is an "oh crap"
> > >> situation, where something is terribly wrong (we hate seeing those).
> > >> Thus, our users may have knee-jerk reactions and not even know to
> > >> inspect the message for the real cause. IAE is less alarming, IMHO.
> > >> Just my $0.02, but we've been doing it that way for a long time in
> > >> [lang], so be it.
> > >>
> > >>
> > >> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> > >> > AFAIK "accidental" NPEs don't have a message associated with them.
> > >> >
> > >> > So provided that the assertion generates the NPE with a suitable
> > >> > message (e.g.as currently done for the IAE) then it *should* be
> > >> > possible for the end user to distinguish the two cases.
> > >> >
> > >> > I am slightly in favour of retaining IAE as the cause is obvious
> with
> > >> > needing to look at the NPE message.
> > >> >
> > >> > ==
> > >> >
> > >> > Horrible hack: - if you want to use NPE, you could wrap an IAE in
> the
> > >> NPE:
> > >> >
> > >> > npe = new NPE(msg);
> > >> > npe.initCause(new IAE(msg));
> > >> > throw npe;
> > >> >
> > >> > Or vice-vera, of course!
> > >> >
> > >> > Not sure that gains anything, but it does make the stack trace look
> > >> > more impressive!
> > >> >
> > >> > On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
> > >> wrote:
> > >> >> Commons Lang's Validate.notNull() throws NPEs. I don't know that
> > I've
> > >> >> necessarily agreed with that, but at some point a decision was made
> > >> >> that null constraint violations should throw NPEs. Food for
> thought.
> > >> >>
> > >> >> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> > garydgregory@gmail.com>
> > >> wrote:
> > >> >>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <
> ebourg@apache.org>
> > >> wrote:
> > >> >>>
> > >> >>>>
> > >> >>>> >> + if (parameter == null) {
> > >> >>>> >> + throw new IllegalArgumentException("Parameter '"
> +
> > >> >>>> parameterName + "' must not be null!");
> > >> >>>> >> + }
> > >> >>>> >> + }
> > >> >>>> >> +}
> > >> >>>>
> > >> >>>> Isn't a null value supposed to throw a NPE ?
> > >> >>>>
> > >> >>>
> > >> >>> Not always IMO. When I see an NPE I assume something is very wrong
> > and
> > >> that
> > >> >>> it could be a bug in the impl OR a call site, somewhere on the
> code
> > >> path.
> > >> >>>
> > >> >>> With an IAE, I know for sure it's a problem in the call site
> (which
> > >> could
> > >> >>> be a bug of course).
> > >> >>>
> > >> >>> I does not help that the JRE/JDK is inconsistent, so it's hard to
> > find
> > >> >>> examples.
> > >> >>>
> > >> >>> Gary
> > >> >>>
> > >> >>>
> > >> >>>> Emmanuel Bourg
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > ---------------------------------------------------------------------
> > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>>
> > >> >>> --
> > >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > >> >>> 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
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Benedikt Ritter <br...@apache.org>.
2013/8/30 sebb <se...@gmail.com>
> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
> > I've removed the generics in r1518974, thanks for spotting that sebb.
> >
> > Regarding the exception to throw I'm indifferent. The important thing is
> to
> > fail early.
> >
>
> ... and with a helpful message.
>
> > I personally thing that NPE should be reserved for signaling that some
> code
> > tried to invoke a method on a null reference.
>
> +1
>
> > In our case null is illegal because we know that some code later on would
> > break if we accept a null reference. So IllegalStateException makes
> sense.
>
> s/IllegalStateException /IllegalArgumentException/
>
> +1
>
Sorry, I meant IAE of corse.
>
> > Imaging having a method that accepts an int and only positive ints are
> > valid. You would throw an IllegalArgumentException if a negative int is
> > passed to that method and not a NegativeIntegerException (or what ever).
> > But James has a point. If [LANG] uses NPE maybe we should stick to this.
>
> I don't think we have to do the same as LANG, so long as the Javadoc is
> clear.
>
> > Feel free to change it. I'll leave it for now since there doesn't seem to
> > be consensus?!
>
> Unless there are other reasons than "LANG happens to use NPE" I think
> we should stick with IAE, as it more clearly indicates the the problem
> is not within the method throwing it.
>
> The problem with using NPE to flag parameter errors is that it
> confuses the user as to the likely cause.
>
> Leave NPEs to the runtime system.
>
agreed.
>
> > Benedikt
> >
> >
> > 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >
> >> Well, the problem with using NPE is that we as Java developers have
> >> learned through the years that NPE typically is an "oh crap"
> >> situation, where something is terribly wrong (we hate seeing those).
> >> Thus, our users may have knee-jerk reactions and not even know to
> >> inspect the message for the real cause. IAE is less alarming, IMHO.
> >> Just my $0.02, but we've been doing it that way for a long time in
> >> [lang], so be it.
> >>
> >>
> >> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> >> > AFAIK "accidental" NPEs don't have a message associated with them.
> >> >
> >> > So provided that the assertion generates the NPE with a suitable
> >> > message (e.g.as currently done for the IAE) then it *should* be
> >> > possible for the end user to distinguish the two cases.
> >> >
> >> > I am slightly in favour of retaining IAE as the cause is obvious with
> >> > needing to look at the NPE message.
> >> >
> >> > ==
> >> >
> >> > Horrible hack: - if you want to use NPE, you could wrap an IAE in the
> >> NPE:
> >> >
> >> > npe = new NPE(msg);
> >> > npe.initCause(new IAE(msg));
> >> > throw npe;
> >> >
> >> > Or vice-vera, of course!
> >> >
> >> > Not sure that gains anything, but it does make the stack trace look
> >> > more impressive!
> >> >
> >> > On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
> >> wrote:
> >> >> Commons Lang's Validate.notNull() throws NPEs. I don't know that
> I've
> >> >> necessarily agreed with that, but at some point a decision was made
> >> >> that null constraint violations should throw NPEs. Food for thought.
> >> >>
> >> >> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> garydgregory@gmail.com>
> >> wrote:
> >> >>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
> >> wrote:
> >> >>>
> >> >>>>
> >> >>>> >> + if (parameter == null) {
> >> >>>> >> + throw new IllegalArgumentException("Parameter '" +
> >> >>>> parameterName + "' must not be null!");
> >> >>>> >> + }
> >> >>>> >> + }
> >> >>>> >> +}
> >> >>>>
> >> >>>> Isn't a null value supposed to throw a NPE ?
> >> >>>>
> >> >>>
> >> >>> Not always IMO. When I see an NPE I assume something is very wrong
> and
> >> that
> >> >>> it could be a bug in the impl OR a call site, somewhere on the code
> >> path.
> >> >>>
> >> >>> With an IAE, I know for sure it's a problem in the call site (which
> >> could
> >> >>> be a bug of course).
> >> >>>
> >> >>> I does not help that the JRE/JDK is inconsistent, so it's hard to
> find
> >> >>> examples.
> >> >>>
> >> >>> Gary
> >> >>>
> >> >>>
> >> >>>> Emmanuel Bourg
> >> >>>>
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>> 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
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 30, 2013 at 10:30 AM, sebb <se...@gmail.com> wrote:
> On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
> > I've removed the generics in r1518974, thanks for spotting that sebb.
> >
> > Regarding the exception to throw I'm indifferent. The important thing is
> to
> > fail early.
> >
>
> ... and with a helpful message.
>
> > I personally thing that NPE should be reserved for signaling that some
> code
> > tried to invoke a method on a null reference.
>
> +1
>
> > In our case null is illegal because we know that some code later on would
> > break if we accept a null reference. So IllegalStateException makes
> sense.
>
> s/IllegalStateException /IllegalArgumentException/
>
> +1
>
> > Imaging having a method that accepts an int and only positive ints are
> > valid. You would throw an IllegalArgumentException if a negative int is
> > passed to that method and not a NegativeIntegerException (or what ever).
> > But James has a point. If [LANG] uses NPE maybe we should stick to this.
>
> I don't think we have to do the same as LANG, so long as the Javadoc is
> clear.
>
> > Feel free to change it. I'll leave it for now since there doesn't seem to
> > be consensus?!
>
> Unless there are other reasons than "LANG happens to use NPE" I think
> we should stick with IAE, as it more clearly indicates the the problem
> is not within the method throwing it.
>
> The problem with using NPE to flag parameter errors is that it
> confuses the user as to the likely cause.
>
> Leave NPEs to the runtime system.
>
I agree with all of Sebb's +1 and arguments.
Gary
>
> > Benedikt
> >
> >
> > 2013/8/30 James Carman <ja...@carmanconsulting.com>
> >
> >> Well, the problem with using NPE is that we as Java developers have
> >> learned through the years that NPE typically is an "oh crap"
> >> situation, where something is terribly wrong (we hate seeing those).
> >> Thus, our users may have knee-jerk reactions and not even know to
> >> inspect the message for the real cause. IAE is less alarming, IMHO.
> >> Just my $0.02, but we've been doing it that way for a long time in
> >> [lang], so be it.
> >>
> >>
> >> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> >> > AFAIK "accidental" NPEs don't have a message associated with them.
> >> >
> >> > So provided that the assertion generates the NPE with a suitable
> >> > message (e.g.as currently done for the IAE) then it *should* be
> >> > possible for the end user to distinguish the two cases.
> >> >
> >> > I am slightly in favour of retaining IAE as the cause is obvious with
> >> > needing to look at the NPE message.
> >> >
> >> > ==
> >> >
> >> > Horrible hack: - if you want to use NPE, you could wrap an IAE in the
> >> NPE:
> >> >
> >> > npe = new NPE(msg);
> >> > npe.initCause(new IAE(msg));
> >> > throw npe;
> >> >
> >> > Or vice-vera, of course!
> >> >
> >> > Not sure that gains anything, but it does make the stack trace look
> >> > more impressive!
> >> >
> >> > On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
> >> wrote:
> >> >> Commons Lang's Validate.notNull() throws NPEs. I don't know that
> I've
> >> >> necessarily agreed with that, but at some point a decision was made
> >> >> that null constraint violations should throw NPEs. Food for thought.
> >> >>
> >> >> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <
> garydgregory@gmail.com>
> >> wrote:
> >> >>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
> >> wrote:
> >> >>>
> >> >>>>
> >> >>>> >> + if (parameter == null) {
> >> >>>> >> + throw new IllegalArgumentException("Parameter '" +
> >> >>>> parameterName + "' must not be null!");
> >> >>>> >> + }
> >> >>>> >> + }
> >> >>>> >> +}
> >> >>>>
> >> >>>> Isn't a null value supposed to throw a NPE ?
> >> >>>>
> >> >>>
> >> >>> Not always IMO. When I see an NPE I assume something is very wrong
> and
> >> that
> >> >>> it could be a bug in the impl OR a call site, somewhere on the code
> >> path.
> >> >>>
> >> >>> With an IAE, I know for sure it's a problem in the call site (which
> >> could
> >> >>> be a bug of course).
> >> >>>
> >> >>> I does not help that the JRE/JDK is inconsistent, so it's hard to
> find
> >> >>> examples.
> >> >>>
> >> >>> Gary
> >> >>>
> >> >>>
> >> >>>> Emmanuel Bourg
> >> >>>>
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> >>> 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
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by sebb <se...@gmail.com>.
On 30 August 2013 15:19, Benedikt Ritter <br...@apache.org> wrote:
> I've removed the generics in r1518974, thanks for spotting that sebb.
>
> Regarding the exception to throw I'm indifferent. The important thing is to
> fail early.
>
... and with a helpful message.
> I personally thing that NPE should be reserved for signaling that some code
> tried to invoke a method on a null reference.
+1
> In our case null is illegal because we know that some code later on would
> break if we accept a null reference. So IllegalStateException makes sense.
s/IllegalStateException /IllegalArgumentException/
+1
> Imaging having a method that accepts an int and only positive ints are
> valid. You would throw an IllegalArgumentException if a negative int is
> passed to that method and not a NegativeIntegerException (or what ever).
> But James has a point. If [LANG] uses NPE maybe we should stick to this.
I don't think we have to do the same as LANG, so long as the Javadoc is clear.
> Feel free to change it. I'll leave it for now since there doesn't seem to
> be consensus?!
Unless there are other reasons than "LANG happens to use NPE" I think
we should stick with IAE, as it more clearly indicates the the problem
is not within the method throwing it.
The problem with using NPE to flag parameter errors is that it
confuses the user as to the likely cause.
Leave NPEs to the runtime system.
> Benedikt
>
>
> 2013/8/30 James Carman <ja...@carmanconsulting.com>
>
>> Well, the problem with using NPE is that we as Java developers have
>> learned through the years that NPE typically is an "oh crap"
>> situation, where something is terribly wrong (we hate seeing those).
>> Thus, our users may have knee-jerk reactions and not even know to
>> inspect the message for the real cause. IAE is less alarming, IMHO.
>> Just my $0.02, but we've been doing it that way for a long time in
>> [lang], so be it.
>>
>>
>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
>> > AFAIK "accidental" NPEs don't have a message associated with them.
>> >
>> > So provided that the assertion generates the NPE with a suitable
>> > message (e.g.as currently done for the IAE) then it *should* be
>> > possible for the end user to distinguish the two cases.
>> >
>> > I am slightly in favour of retaining IAE as the cause is obvious with
>> > needing to look at the NPE message.
>> >
>> > ==
>> >
>> > Horrible hack: - if you want to use NPE, you could wrap an IAE in the
>> NPE:
>> >
>> > npe = new NPE(msg);
>> > npe.initCause(new IAE(msg));
>> > throw npe;
>> >
>> > Or vice-vera, of course!
>> >
>> > Not sure that gains anything, but it does make the stack trace look
>> > more impressive!
>> >
>> > On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
>> wrote:
>> >> Commons Lang's Validate.notNull() throws NPEs. I don't know that I've
>> >> necessarily agreed with that, but at some point a decision was made
>> >> that null constraint violations should throw NPEs. Food for thought.
>> >>
>> >> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
>> wrote:
>> >>>
>> >>>>
>> >>>> >> + if (parameter == null) {
>> >>>> >> + throw new IllegalArgumentException("Parameter '" +
>> >>>> parameterName + "' must not be null!");
>> >>>> >> + }
>> >>>> >> + }
>> >>>> >> +}
>> >>>>
>> >>>> Isn't a null value supposed to throw a NPE ?
>> >>>>
>> >>>
>> >>> Not always IMO. When I see an NPE I assume something is very wrong and
>> that
>> >>> it could be a bug in the impl OR a call site, somewhere on the code
>> path.
>> >>>
>> >>> With an IAE, I know for sure it's a problem in the call site (which
>> could
>> >>> be a bug of course).
>> >>>
>> >>> I does not help that the JRE/JDK is inconsistent, so it's hard to find
>> >>> examples.
>> >>>
>> >>> Gary
>> >>>
>> >>>
>> >>>> Emmanuel Bourg
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>> 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
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Benedikt Ritter <br...@apache.org>.
I've removed the generics in r1518974, thanks for spotting that sebb.
Regarding the exception to throw I'm indifferent. The important thing is to
fail early.
I personally thing that NPE should be reserved for signaling that some code
tried to invoke a method on a null reference.
In our case null is illegal because we know that some code later on would
break if we accept a null reference. So IllegalStateException makes sense.
Imaging having a method that accepts an int and only positive ints are
valid. You would throw an IllegalArgumentException if a negative int is
passed to that method and not a NegativeIntegerException (or what ever).
But James has a point. If [LANG] uses NPE maybe we should stick to this.
Feel free to change it. I'll leave it for now since there doesn't seem to
be consensus?!
Benedikt
2013/8/30 James Carman <ja...@carmanconsulting.com>
> Well, the problem with using NPE is that we as Java developers have
> learned through the years that NPE typically is an "oh crap"
> situation, where something is terribly wrong (we hate seeing those).
> Thus, our users may have knee-jerk reactions and not even know to
> inspect the message for the real cause. IAE is less alarming, IMHO.
> Just my $0.02, but we've been doing it that way for a long time in
> [lang], so be it.
>
>
> On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> > AFAIK "accidental" NPEs don't have a message associated with them.
> >
> > So provided that the assertion generates the NPE with a suitable
> > message (e.g.as currently done for the IAE) then it *should* be
> > possible for the end user to distinguish the two cases.
> >
> > I am slightly in favour of retaining IAE as the cause is obvious with
> > needing to look at the NPE message.
> >
> > ==
> >
> > Horrible hack: - if you want to use NPE, you could wrap an IAE in the
> NPE:
> >
> > npe = new NPE(msg);
> > npe.initCause(new IAE(msg));
> > throw npe;
> >
> > Or vice-vera, of course!
> >
> > Not sure that gains anything, but it does make the stack trace look
> > more impressive!
> >
> > On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com>
> wrote:
> >> Commons Lang's Validate.notNull() throws NPEs. I don't know that I've
> >> necessarily agreed with that, but at some point a decision was made
> >> that null constraint violations should throw NPEs. Food for thought.
> >>
> >> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org>
> wrote:
> >>>
> >>>>
> >>>> >> + if (parameter == null) {
> >>>> >> + throw new IllegalArgumentException("Parameter '" +
> >>>> parameterName + "' must not be null!");
> >>>> >> + }
> >>>> >> + }
> >>>> >> +}
> >>>>
> >>>> Isn't a null value supposed to throw a NPE ?
> >>>>
> >>>
> >>> Not always IMO. When I see an NPE I assume something is very wrong and
> that
> >>> it could be a bug in the impl OR a call site, somewhere on the code
> path.
> >>>
> >>> With an IAE, I know for sure it's a problem in the call site (which
> could
> >>> be a bug of course).
> >>>
> >>> I does not help that the JRE/JDK is inconsistent, so it's hard to find
> >>> examples.
> >>>
> >>> Gary
> >>>
> >>>
> >>>> Emmanuel Bourg
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> 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
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
Well, the problem with using NPE is that we as Java developers have
learned through the years that NPE typically is an "oh crap"
situation, where something is terribly wrong (we hate seeing those).
Thus, our users may have knee-jerk reactions and not even know to
inspect the message for the real cause. IAE is less alarming, IMHO.
Just my $0.02, but we've been doing it that way for a long time in
[lang], so be it.
On Fri, Aug 30, 2013 at 9:01 AM, sebb <se...@gmail.com> wrote:
> AFAIK "accidental" NPEs don't have a message associated with them.
>
> So provided that the assertion generates the NPE with a suitable
> message (e.g.as currently done for the IAE) then it *should* be
> possible for the end user to distinguish the two cases.
>
> I am slightly in favour of retaining IAE as the cause is obvious with
> needing to look at the NPE message.
>
> ==
>
> Horrible hack: - if you want to use NPE, you could wrap an IAE in the NPE:
>
> npe = new NPE(msg);
> npe.initCause(new IAE(msg));
> throw npe;
>
> Or vice-vera, of course!
>
> Not sure that gains anything, but it does make the stack trace look
> more impressive!
>
> On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com> wrote:
>> Commons Lang's Validate.notNull() throws NPEs. I don't know that I've
>> necessarily agreed with that, but at some point a decision was made
>> that null constraint violations should throw NPEs. Food for thought.
>>
>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>>>
>>>> >> + if (parameter == null) {
>>>> >> + throw new IllegalArgumentException("Parameter '" +
>>>> parameterName + "' must not be null!");
>>>> >> + }
>>>> >> + }
>>>> >> +}
>>>>
>>>> Isn't a null value supposed to throw a NPE ?
>>>>
>>>
>>> Not always IMO. When I see an NPE I assume something is very wrong and that
>>> it could be a bug in the impl OR a call site, somewhere on the code path.
>>>
>>> With an IAE, I know for sure it's a problem in the call site (which could
>>> be a bug of course).
>>>
>>> I does not help that the JRE/JDK is inconsistent, so it's hard to find
>>> examples.
>>>
>>> Gary
>>>
>>>
>>>> Emmanuel Bourg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by sebb <se...@gmail.com>.
AFAIK "accidental" NPEs don't have a message associated with them.
So provided that the assertion generates the NPE with a suitable
message (e.g.as currently done for the IAE) then it *should* be
possible for the end user to distinguish the two cases.
I am slightly in favour of retaining IAE as the cause is obvious with
needing to look at the NPE message.
==
Horrible hack: - if you want to use NPE, you could wrap an IAE in the NPE:
npe = new NPE(msg);
npe.initCause(new IAE(msg));
throw npe;
Or vice-vera, of course!
Not sure that gains anything, but it does make the stack trace look
more impressive!
On 30 August 2013 13:42, James Carman <ja...@carmanconsulting.com> wrote:
> Commons Lang's Validate.notNull() throws NPEs. I don't know that I've
> necessarily agreed with that, but at some point a decision was made
> that null constraint violations should throw NPEs. Food for thought.
>
> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>>>
>>> >> + if (parameter == null) {
>>> >> + throw new IllegalArgumentException("Parameter '" +
>>> parameterName + "' must not be null!");
>>> >> + }
>>> >> + }
>>> >> +}
>>>
>>> Isn't a null value supposed to throw a NPE ?
>>>
>>
>> Not always IMO. When I see an NPE I assume something is very wrong and that
>> it could be a bug in the impl OR a call site, somewhere on the code path.
>>
>> With an IAE, I know for sure it's a problem in the call site (which could
>> be a bug of course).
>>
>> I does not help that the JRE/JDK is inconsistent, so it's hard to find
>> examples.
>>
>> Gary
>>
>>
>>> Emmanuel Bourg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by James Carman <ja...@carmanconsulting.com>.
Commons Lang's Validate.notNull() throws NPEs. I don't know that I've
necessarily agreed with that, but at some point a decision was made
that null constraint violations should throw NPEs. Food for thought.
On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
>>
>> >> + if (parameter == null) {
>> >> + throw new IllegalArgumentException("Parameter '" +
>> parameterName + "' must not be null!");
>> >> + }
>> >> + }
>> >> +}
>>
>> Isn't a null value supposed to throw a NPE ?
>>
>
> Not always IMO. When I see an NPE I assume something is very wrong and that
> it could be a bug in the impl OR a call site, somewhere on the code path.
>
> With an IAE, I know for sure it's a problem in the call site (which could
> be a bug of course).
>
> I does not help that the JRE/JDK is inconsistent, so it's hard to find
> examples.
>
> Gary
>
>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> >> + if (parameter == null) {
> >> + throw new IllegalArgumentException("Parameter '" +
> parameterName + "' must not be null!");
> >> + }
> >> + }
> >> +}
>
> Isn't a null value supposed to throw a NPE ?
>
Not always IMO. When I see an NPE I assume something is very wrong and that
it could be a bug in the impl OR a call site, somewhere on the code path.
With an IAE, I know for sure it's a problem in the call site (which could
be a bug of course).
I does not help that the JRE/JDK is inconsistent, so it's hard to find
examples.
Gary
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src: main/java/org/apache/commons/csv/
test/java/org/apache/commons/csv/
Posted by Emmanuel Bourg <eb...@apache.org>.
>> + if (parameter == null) {
>> + throw new IllegalArgumentException("Parameter '" + parameterName + "' must not be null!");
>> + }
>> + }
>> +}
Isn't a null value supposed to throw a NPE ?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1518802 - in /commons/proper/csv/trunk/src:
main/java/org/apache/commons/csv/ test/java/org/apache/commons/csv/
Posted by sebb <se...@gmail.com>.
On 29 August 2013 21:18, <br...@apache.org> wrote:
> Author: britter
> Date: Thu Aug 29 20:18:13 2013
> New Revision: 1518802
>
> URL: http://svn.apache.org/r1518802
> Log:
> Make methods that create parsers or printers fail early and provide an expressive error messages. Document new behavior in JavaDoc
>
> Added:
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java (with props)
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/AssertionsTest.java (with props)
> Modified:
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java
> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
>
> Added: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java
> URL: http://svn.apache.org/viewvc/commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java?rev=1518802&view=auto
> ==============================================================================
> --- commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java (added)
> +++ commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Assertions.java Thu Aug 29 20:18:13 2013
> @@ -0,0 +1,19 @@
> +package org.apache.commons.csv;
> +
> +/**
> + * Utility class for input parameter validation
> + *
> + * @version $Id$
> + */
> +final class Assertions {
> +
> + private Assertions() {
> + // can not be instantiated
> + }
> +
> + public static <T> void notNull(T parameter, String parameterName) {
Not sure this needs to be generic. Surely could just use the following
method sig?
public static void notNull(Object parameter, String parameterName) {
> + if (parameter == null) {
> + throw new IllegalArgumentException("Parameter '" + parameterName + "' must not be null!");
> + }
> + }
> +}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org