On 08/27/2013 08:23 PM, Oliver Heger wrote:
> Am 27.08.2013 15:57, schrieb Phil Steitz:
>> On 8/27/13 6:31 AM, James Carman wrote:
>>> It was mentioned the other day, so I thought I would propose a formal
>>> discussion. Is it time to let [math] "leave the nest"? I would doubt
>>> there are very
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.
How often do you really want to catch these?
Matt
On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory 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-
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, A
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:seb...@gmail.com]
Sent: Friday,
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 wrote:
> The discussion for [lang], none of whose participants have
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://m
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
viewpoint
The JDK Javadoc says of NPE:
* Applications should throw instances of this class to indicate
* other illegal uses of the null 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 JD
Hi,
in r1518802 [1] I have introduced some parameter validation. This was the
result of a discussion we had some time ago [2], where we agreed there
shouldn't be any fallbacks if null is passed to one of the static creation
methods on CSVParser. Now there is one method left that still uses a
fallb
On Fri, Aug 30, 2013 at 10:30 AM, sebb wrote:
> On 30 August 2013 15:19, Benedikt Ritter 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 h
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 th
2013/8/30 sebb
> On 30 August 2013 15:19, Benedikt Ritter 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 persona
On 30 August 2013 15:19, Benedikt Ritter 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
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
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 ca
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 t
Thanks for this analysis. In my case, I require the more generic version
with overlapping variable sets for component functions. Also, I need to
worry about multiplication of component functions too.
I'll think about the most efficient way to do this.
Cheers,
Ajo.
On Fri, Aug 30, 2013 at 12:21
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 wrote:
> On Fri, Aug 30, 2013 at 8:25 AM,
On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg wrote:
>
> >> +if (parameter == null) {
> >> +throw new IllegalArgumentException("Parameter '" +
> parameterName + "' must not be null!");
> >> +}
> >> +}
> >> +}
>
> Isn't a null value supposed to throw a NPE ?
>
No
>> +if (parameter == null) {
>> +throw new IllegalArgumentException("Parameter '" +
>> parameterName + "' must not be null!");
>> +}
>> +}
>> +}
Isn't a null value supposed to throw a NPE ?
Emmanuel Bourg
On 29 August 2013 21:18, 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
>
> Add
Hi Ajo,
Le 29/08/2013 19:05, Ajo Fod a écrit :
> Hello,
>
> I wonder if the number of computations required to compute a derivative
> structure can be reduced. Say the derivative structure of f to order d=2 is
> desired:
> f(g1(x1), g2(x2), ... gn(xn)) where x1,x2 ... xn are subsets of variables
23 matches
Mail list logo
