You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by lu...@apache.org on 2010/08/01 17:27:20 UTC
svn commit: r981244 - in /commons/proper/math/trunk/src/main:
java/org/apache/commons/math/ java/org/apache/commons/math/linear/
java/org/apache/commons/math/util/ resources/META-INF/localization/
Author: luc
Date: Sun Aug 1 15:27:20 2010
New Revision: 981244
URL: http://svn.apache.org/viewvc?rev=981244&view=rev
Log:
Added a localized UnsupportedOperationException
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/MathRuntimeException.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/AbstractRealVector.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/LocalizedFormats.java
commons/proper/math/trunk/src/main/resources/META-INF/localization/LocalizedFormats_fr.properties
Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/MathRuntimeException.java
URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/MathRuntimeException.java?rev=981244&r1=981243&r2=981244&view=diff
==============================================================================
--- commons/proper/math/trunk/src/main/java/org/apache/commons/math/MathRuntimeException.java (original)
+++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/MathRuntimeException.java Sun Aug 1 15:27:20 2010
@@ -550,6 +550,36 @@ public class MathRuntimeException extend
}
/**
+ * Constructs a new <code>UnsupportedOperationException</code> with specified formatted detail message.
+ * Message formatting is delegated to {@link java.text.MessageFormat}.
+ * @param pattern format specifier
+ * @param arguments format arguments
+ * @return built exception
+ * @since 2.2
+ */
+ public static UnsupportedOperationException createUnsupportedOperationException(final Localizable pattern,
+ final Object ... arguments) {
+ return new UnsupportedOperationException() {
+
+ /** Serializable version identifier. */
+ private static final long serialVersionUID = -4284649691002411505L;
+
+ /** {@inheritDoc} */
+ @Override
+ public String getMessage() {
+ return buildMessage(Locale.US, pattern, arguments);
+ }
+
+ /** {@inheritDoc} */
+ @Override
+ public String getLocalizedMessage() {
+ return buildMessage(Locale.getDefault(), pattern, arguments);
+ }
+
+ };
+ }
+
+ /**
* Constructs a new <code>NullPointerException</code> with specified formatted detail message.
* Message formatting is delegated to {@link java.text.MessageFormat}.
* @param pattern format specifier
Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/AbstractRealVector.java
URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/AbstractRealVector.java?rev=981244&r1=981243&r2=981244&view=diff
==============================================================================
--- commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/AbstractRealVector.java (original)
+++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/linear/AbstractRealVector.java Sun Aug 1 15:27:20 2010
@@ -23,8 +23,8 @@ import java.util.NoSuchElementException;
import org.apache.commons.math.FunctionEvaluationException;
import org.apache.commons.math.MathRuntimeException;
import org.apache.commons.math.analysis.BinaryFunction;
-import org.apache.commons.math.analysis.UnivariateRealFunction;
import org.apache.commons.math.analysis.ComposableFunction;
+import org.apache.commons.math.analysis.UnivariateRealFunction;
import org.apache.commons.math.util.LocalizedFormats;
/**
@@ -816,7 +816,7 @@ public abstract class AbstractRealVector
/** {@inheritDoc} */
public void remove() {
- throw new UnsupportedOperationException("Not supported");
+ throw MathRuntimeException.createUnsupportedOperationException(LocalizedFormats.UNSUPPORTED_OPERATION);
}
};
}
@@ -924,7 +924,7 @@ public abstract class AbstractRealVector
/** {@inheritDoc} */
public void remove() {
- throw new UnsupportedOperationException("Not supported");
+ throw MathRuntimeException.createUnsupportedOperationException(LocalizedFormats.UNSUPPORTED_OPERATION);
}
}
Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/LocalizedFormats.java
URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/LocalizedFormats.java?rev=981244&r1=981243&r2=981244&view=diff
==============================================================================
--- commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/LocalizedFormats.java (original)
+++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/LocalizedFormats.java Sun Aug 1 15:27:20 2010
@@ -278,6 +278,7 @@ public enum LocalizedFormats implements
UNPARSEABLE_FRACTION_NUMBER("unparseable fraction number: \"{0}\""),
UNPARSEABLE_REAL_VECTOR("unparseable real vector: \"{0}\""),
UNSUPPORTED_EXPANSION_MODE("unsupported expansion mode {0}, supported modes are {1} ({2}) and {3} ({4})"),
+ UNSUPPORTED_OPERATION("unsupported operation"),
URL_CONTAINS_NO_DATA("URL {0} contains no data"),
VALUES_ADDED_BEFORE_CONFIGURING_STATISTIC("{0} values have been added before statistic is configured"),
VECTOR_LENGTH_MISMATCH("vector length mismatch: got {0} but expected {1}"),
Modified: commons/proper/math/trunk/src/main/resources/META-INF/localization/LocalizedFormats_fr.properties
URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/resources/META-INF/localization/LocalizedFormats_fr.properties?rev=981244&r1=981243&r2=981244&view=diff
==============================================================================
--- commons/proper/math/trunk/src/main/resources/META-INF/localization/LocalizedFormats_fr.properties (original)
+++ commons/proper/math/trunk/src/main/resources/META-INF/localization/LocalizedFormats_fr.properties Sun Aug 1 15:27:20 2010
@@ -248,7 +248,8 @@ UNPARSEABLE_3D_VECTOR = vecteur 3D non a
UNPARSEABLE_COMPLEX_NUMBER = nombre complexe non analysable : "{0}"
UNPARSEABLE_FRACTION_NUMBER = nombre fractionnaire non analysable : "{0}"
UNPARSEABLE_REAL_VECTOR = vecteur r\u00e9el non analysable : "{0}"
-UNSUPPORTED_EXPANSION_MODE = mode d''extension {0} no support\u00e9, les modes support\u00e9s sont {1} ({2}) et {3} ({4})
+UNSUPPORTED_EXPANSION_MODE = mode d''extension {0} non support\u00e9, les modes support\u00e9s sont {1} ({2}) et {3} ({4})
+UNSUPPORTED_OPERATION = op\u00e9ration non disponible
URL_CONTAINS_NO_DATA = l''adresse {0} ne contient aucune donn\u00e9e
VALUES_ADDED_BEFORE_CONFIGURING_STATISTIC = {0} valeurs ont \u00e9t\u00e9 ajout\u00e9es
VECTOR_LENGTH_MISMATCH = taille de vecteur invalide : {0} au lieu de {1} attendue
Re: [Math] Usage of "NullPointerException"
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 04/08/2010 23:27, Gilles Sadowski a écrit :
>>> A simpler policy would be to not check for "null" and let the JVM do it. As
>>> the JVM will do it anyway, it's a redundant check when the reference is not
>>> null, i.e. most of time (in legitimate usage).
>>
>> This simpler policy seems fine to me.
>> However, it is an important change from previous behaviour.
>
> In practice it is not that important: there are currently only 29
> occurrences of messages referring to "null"; among those only 6 raise a
> NullPointerException (the others throw an IllegalArgumentException).
>
>>> When the usage is wrong, the error is obvious and always the same ("null
>>> reference") and the "NullPointerException" fully identify the problem. I
>>> don't see why we should have a localized version of it. Yes, again, there
>>> are detailed messages saying:
>>> "the covariance matrix cannot be null"
>>> "the function cannot be null"
>>> "the denominator cannot be null"
>>> etc.
>>> But since any reference can potentially be "null", do you really intend to
>>> have a specific meesage for every object?
>>
>> For these very low level errors, I would be happy with the single
>> message from JVM.
>
> So, shall I remove all checks for "null" (and those items in
> "LocalizedFormats" that are used for reporting it)?
> Should I open a JIRA issue?
Lets wait from what others think about this.
Luc
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >There may be some cases where it makes sense to propagate NPEs
> >directly. I don't see any in the code now, but I would not rule it
> >out for the future. I am fine, however, dispensing with
> >MathRuntimeException.createNullPointerException (that's what I meant
> >by "wrapped NPE." Technically, you are right, the resultant NPE is
> >not really "wrapped," just specialized.) Where we throw IAE today
> >with informative error message indicating which parameter was null,
> >I want to retain the error message.
> >
>
> There are actually quite a few places were we propagate NPEs
> directly. For example PolynomialFunction does this pretty much
> everywhere that the JavaDocs says that it throws a NPE.
So this must be changed. I'll file a report.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Math] Redundant messages (Was: Usage of "NullPointerException")
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> On another front, the separation between "general" and "specific" error
> message patterns can save some more enums [...]
More on this. Excerpt from "LocalizedFormats.java":
NEGATIVE_LENGTH("length cannot be negative ({0})"),
// ...
NOT_POSITIVE_LENGTH("length must be positive ({0})"),
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> What I propose (as an alternative the "simple" policy) above is to create
> a "NullArgumentException" that inherits from "MathIllegalArgumentException".
> This exception will be thrown whenever a null check fails (i.e. "null is an
> illegal argument"). To be consistent, we should never throw NPE from CM.
I'm converting all current uses of the "createIllegalArgument" over to
throwing "NullArgumentException".
While at that, I noticed there is another kind of inconsistency when dealing
with method arguments. In code like
---CUT---
if (den == 0) {
throw MathRuntimeException.createArithmeticException(
LocalizedFormats.ZERO_DENOMINATOR_IN_FRACTION, num, den);
}
---CUT---
One should throw a "ZeroException" (subclass of "IllegalArgumentException"),
instead of an "ArithmeticException", to folow the rationale that we settled
on (of throwing IAE instead of NPE for null arguments).
On another front, the separation between "general" and "specific" error
message patterns can save some more enums like in the above example (in the
"Fraction" class) where the modified code would look like:
---CUT---
if (den == 0) {
throw new ZeroException(LocalizedFormats.DENOMINATOR);
}
---CUT---
[Propagating the numerator is not relevant. Otherwise, where do you stop
in providing "context"? For every method you could consider that the whole
parameter list must be part of the detailed message...]
And, for the numerator check, we would have the equivalent:
---CUT---
if (num == 0) {
throw new ZeroException(LocalizedFormats.NUMERATOR);
}
---CUT---
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException"
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Phil Steitz" <ph...@gmail.com>
Sent: Friday, August 06, 2010 3:34 AM
To: "Commons Developers List" <de...@commons.apache.org>
Subject: Re: [Math] Usage of "NullPointerException"
> Gilles Sadowski wrote:
>>>>> The added value that I see is that an IAE designating which argument
>>>>> that cannot be null is in fact null gives more specific information
>>>>> to the caller (or production support person examining logs) than
>>>>> just a propagated NPE.
>>>> Well, my initial post reported the inconsistency of throwing either NPE
>>>> or
>>>> IAE as a result of checking for "null". If we take that NPE signifies a
>>>> bug
>>>> in CM, then we can have the policy of throwing IAE when null is
>>>> encountered
>>>> (and never explicitly throw NPE from CM).
>>>>
>>> +1 - that is what I meant by my option 1) above.
>>
>> This was your option 1:
>>
>>>> 1) remove NPE wrappers, propagating uwrapped NPEs where the code
>>>> wraps and rethrows NPE today.
>>
>> As I said, there are no wrappers around the NPE generated in CM. Either
>> "createNullPointerException" or "createIllegalArgumentException" is
>> called
>> and they generate the corresponding exception (not wrapped within
>> anything).
>>
>> What I propose (as an alternative the "simple" policy) above is to create
>> a "NullArgumentException" that inherits from
>> "MathIllegalArgumentException".
>> This exception will be thrown whenever a null check fails (i.e. "null is
>> an
>> illegal argument"). To be consistent, we should never throw NPE from CM.
>> Is that what you meant to agree with?
>
> There may be some cases where it makes sense to propagate NPEs
> directly. I don't see any in the code now, but I would not rule it
> out for the future. I am fine, however, dispensing with
> MathRuntimeException.createNullPointerException (that's what I meant
> by "wrapped NPE." Technically, you are right, the resultant NPE is
> not really "wrapped," just specialized.) Where we throw IAE today
> with informative error message indicating which parameter was null,
> I want to retain the error message.
>
There are actually quite a few places were we propagate NPEs directly. For
example PolynomialFunction does this pretty much everywhere that the
JavaDocs says that it throws a NPE.
> Phil
>
>
>>
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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: [Math] Usage of "NullPointerException"
Posted by Phil Steitz <ph...@gmail.com>.
Gilles Sadowski wrote:
>>>> The added value that I see is that an IAE designating which argument
>>>> that cannot be null is in fact null gives more specific information
>>>> to the caller (or production support person examining logs) than
>>>> just a propagated NPE.
>>> Well, my initial post reported the inconsistency of throwing either NPE or
>>> IAE as a result of checking for "null". If we take that NPE signifies a bug
>>> in CM, then we can have the policy of throwing IAE when null is encountered
>>> (and never explicitly throw NPE from CM).
>>>
>> +1 - that is what I meant by my option 1) above.
>
> This was your option 1:
>
>>> 1) remove NPE wrappers, propagating uwrapped NPEs where the code
>>> wraps and rethrows NPE today.
>
> As I said, there are no wrappers around the NPE generated in CM. Either
> "createNullPointerException" or "createIllegalArgumentException" is called
> and they generate the corresponding exception (not wrapped within anything).
>
> What I propose (as an alternative the "simple" policy) above is to create
> a "NullArgumentException" that inherits from "MathIllegalArgumentException".
> This exception will be thrown whenever a null check fails (i.e. "null is an
> illegal argument"). To be consistent, we should never throw NPE from CM.
> Is that what you meant to agree with?
There may be some cases where it makes sense to propagate NPEs
directly. I don't see any in the code now, but I would not rule it
out for the future. I am fine, however, dispensing with
MathRuntimeException.createNullPointerException (that's what I meant
by "wrapped NPE." Technically, you are right, the resultant NPE is
not really "wrapped," just specialized.) Where we throw IAE today
with informative error message indicating which parameter was null,
I want to retain the error message.
Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >> The added value that I see is that an IAE designating which argument
> >> that cannot be null is in fact null gives more specific information
> >> to the caller (or production support person examining logs) than
> >> just a propagated NPE.
> >
> > Well, my initial post reported the inconsistency of throwing either NPE or
> > IAE as a result of checking for "null". If we take that NPE signifies a bug
> > in CM, then we can have the policy of throwing IAE when null is encountered
> > (and never explicitly throw NPE from CM).
> >
>
> +1 - that is what I meant by my option 1) above.
This was your option 1:
>> 1) remove NPE wrappers, propagating uwrapped NPEs where the code
>> wraps and rethrows NPE today.
As I said, there are no wrappers around the NPE generated in CM. Either
"createNullPointerException" or "createIllegalArgumentException" is called
and they generate the corresponding exception (not wrapped within anything).
What I propose (as an alternative the "simple" policy) above is to create
a "NullArgumentException" that inherits from "MathIllegalArgumentException".
This exception will be thrown whenever a null check fails (i.e. "null is an
illegal argument"). To be consistent, we should never throw NPE from CM.
Is that what you meant to agree with?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException"
Posted by Phil Steitz <ph...@gmail.com>.
Gilles Sadowski wrote:
>> [...]
>>
>>> I think that using IAE instead of NPE does not bring any added value. It
>>> justs goes against standard usage: throw NPE when a reference is "null"
>>> and is not allowed to be so.
>>> As proposed in
>>> https://issues.apache.org/jira/browse/MATH-401
>>> we could still do explicit checks for "null" but nevertheless throw the
>>> standard (non-specific and non localized) NPE.
>>>
>> The added value that I see is that an IAE designating which argument
>> that cannot be null is in fact null gives more specific information
>> to the caller (or production support person examining logs) than
>> just a propagated NPE.
>
> Well, my initial post reported the inconsistency of throwing either NPE or
> IAE as a result of checking for "null". If we take that NPE signifies a bug
> in CM, then we can have the policy of throwing IAE when null is encountered
> (and never explicitly throw NPE from CM).
>
+1 - that is what I meant by my option 1) above.
Phil
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> [...]
>
> > I think that using IAE instead of NPE does not bring any added value. It
> > justs goes against standard usage: throw NPE when a reference is "null"
> > and is not allowed to be so.
> > As proposed in
> > https://issues.apache.org/jira/browse/MATH-401
> > we could still do explicit checks for "null" but nevertheless throw the
> > standard (non-specific and non localized) NPE.
> >
> The added value that I see is that an IAE designating which argument
> that cannot be null is in fact null gives more specific information
> to the caller (or production support person examining logs) than
> just a propagated NPE.
Well, my initial post reported the inconsistency of throwing either NPE or
IAE as a result of checking for "null". If we take that NPE signifies a bug
in CM, then we can have the policy of throwing IAE when null is encountered
(and never explicitly throw NPE from CM).
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException"
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 05/08/2010 16:26, Phil Steitz a écrit :
> Gilles Sadowski wrote:
>>>> As proposed in
>>>> https://issues.apache.org/jira/browse/MATH-401
>>>> we could still do explicit checks for "null" but nevertheless throw the
>>>> standard (non-specific and non localized) NPE.
>>>>
>>> The added value that I see is that an IAE designating which argument
>>> that cannot be null is in fact null gives more specific information
>>> to the caller (or production support person examining logs) than
>>> just a propagated NPE.
>>
>> My argument is again "What can he do with that information? Nothing but
>> report the bug to the application developer."
>> Early failure (by explicitly throwing NPE as soon as the problem is
>> detected) to pinpoint the cause is fine, but going beyond that (e.g.
>> using a specific error message for each type found in CM) is not added
>> value; it's bloated code.
>
> No, it is providing full information on the failure, which is very
> useful when troubleshooting problems during development and
> production. There is a reason that Java exception classes have a
> "message" property. Developers who construct useful and informative
> exception error messages are doing their users a big favor. I do
> not want to see us take backward steps in this area.
I second that.
Luc
>
> Phil
>>
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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: [Math] Usage of "NullPointerException"
Posted by Phil Steitz <ph...@gmail.com>.
Gilles Sadowski wrote:
>>> As proposed in
>>> https://issues.apache.org/jira/browse/MATH-401
>>> we could still do explicit checks for "null" but nevertheless throw the
>>> standard (non-specific and non localized) NPE.
>>>
>> The added value that I see is that an IAE designating which argument
>> that cannot be null is in fact null gives more specific information
>> to the caller (or production support person examining logs) than
>> just a propagated NPE.
>
> My argument is again "What can he do with that information? Nothing but
> report the bug to the application developer."
> Early failure (by explicitly throwing NPE as soon as the problem is
> detected) to pinpoint the cause is fine, but going beyond that (e.g.
> using a specific error message for each type found in CM) is not added
> value; it's bloated code.
No, it is providing full information on the failure, which is very
useful when troubleshooting problems during development and
production. There is a reason that Java exception classes have a
"message" property. Developers who construct useful and informative
exception error messages are doing their users a big favor. I do
not want to see us take backward steps in this area.
Phil
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > As proposed in
> > https://issues.apache.org/jira/browse/MATH-401
> > we could still do explicit checks for "null" but nevertheless throw the
> > standard (non-specific and non localized) NPE.
> >
> The added value that I see is that an IAE designating which argument
> that cannot be null is in fact null gives more specific information
> to the caller (or production support person examining logs) than
> just a propagated NPE.
My argument is again "What can he do with that information? Nothing but
report the bug to the application developer."
Early failure (by explicitly throwing NPE as soon as the problem is
detected) to pinpoint the cause is fine, but going beyond that (e.g.
using a specific error message for each type found in CM) is not added
value; it's bloated code.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException"
Posted by Phil Steitz <ph...@gmail.com>.
Gilles Sadowski wrote:
>>>>> A simpler policy would be to not check for "null" and let the JVM do it. As
>>>>> the JVM will do it anyway, it's a redundant check when the reference is not
>>>>> null, i.e. most of time (in legitimate usage).
>>>> This simpler policy seems fine to me.
>>>> However, it is an important change from previous behaviour.
>> Sorry, I am not sure I understand what you mean by the "simpler
>> policy." Which one do you mean:
>>
>> 0) remove null checks uniformly and just let NPEs propagate everywhere
>
> Yes.
>
>> 1) remove NPE wrappers, propagating uwrapped NPEs where the code
>> wraps and rethrows NPE today.
>
> I don't understand this. I didn't find occurrences where a NPE is wrapped
> into something else.
I was referring to the MathRuntimeExceptions.
>
>> 2) other?
>>
>> I am -1 on 0), since this would result in loss of FFC info available
>> in the cases where we rethrow NPE as IAE with an exception message
>> indicating which argument was null (like the examples below).
>
> What does FFC mean?
First failure capture - information available to the caller when a
failure occurs. If we do not generate a message or persist in an
exception property an indication of what argument was null, we
remove information that is available to the caller today. We have
discussed this before. I am in general OK with changing the way we
manage localization, etc., but -1 on removing information from stack
traces.
> I think that using IAE instead of NPE does not bring any added value. It
> justs goes against standard usage: throw NPE when a reference is "null"
> and is not allowed to be so.
> As proposed in
> https://issues.apache.org/jira/browse/MATH-401
> we could still do explicit checks for "null" but nevertheless throw the
> standard (non-specific and non localized) NPE.
>
The added value that I see is that an IAE designating which argument
that cannot be null is in fact null gives more specific information
to the caller (or production support person examining logs) than
just a propagated NPE.
Phil
>> [...]
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> >>> A simpler policy would be to not check for "null" and let the JVM do it. As
> >>> the JVM will do it anyway, it's a redundant check when the reference is not
> >>> null, i.e. most of time (in legitimate usage).
> >> This simpler policy seems fine to me.
> >> However, it is an important change from previous behaviour.
>
> Sorry, I am not sure I understand what you mean by the "simpler
> policy." Which one do you mean:
>
> 0) remove null checks uniformly and just let NPEs propagate everywhere
Yes.
> 1) remove NPE wrappers, propagating uwrapped NPEs where the code
> wraps and rethrows NPE today.
I don't understand this. I didn't find occurrences where a NPE is wrapped
into something else.
> 2) other?
>
> I am -1 on 0), since this would result in loss of FFC info available
> in the cases where we rethrow NPE as IAE with an exception message
> indicating which argument was null (like the examples below).
What does FFC mean?
I think that using IAE instead of NPE does not bring any added value. It
justs goes against standard usage: throw NPE when a reference is "null"
and is not allowed to be so.
As proposed in
https://issues.apache.org/jira/browse/MATH-401
we could still do explicit checks for "null" but nevertheless throw the
standard (non-specific and non localized) NPE.
> [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException"
Posted by Phil Steitz <ph...@gmail.com>.
Gilles Sadowski wrote:
>>> A simpler policy would be to not check for "null" and let the JVM do it. As
>>> the JVM will do it anyway, it's a redundant check when the reference is not
>>> null, i.e. most of time (in legitimate usage).
>> This simpler policy seems fine to me.
>> However, it is an important change from previous behaviour.
Sorry, I am not sure I understand what you mean by the "simpler
policy." Which one do you mean:
0) remove null checks uniformly and just let NPEs propagate everywhere
1) remove NPE wrappers, propagating uwrapped NPEs where the code
wraps and rethrows NPE today.
2) other?
I am -1 on 0), since this would result in loss of FFC info available
in the cases where we rethrow NPE as IAE with an exception message
indicating which argument was null (like the examples below).
If what you mean is 1), I am OK with the change; but we should make
the changes in the 3.0 branch as this could break apps that catch
the wrapped exception (unless I am missing something).
Phil
>
> In practice it is not that important: there are currently only 29
> occurrences of messages referring to "null"; among those only 6 raise a
> NullPointerException (the others throw an IllegalArgumentException).
>
>>> When the usage is wrong, the error is obvious and always the same ("null
>>> reference") and the "NullPointerException" fully identify the problem. I
>>> don't see why we should have a localized version of it. Yes, again, there
>>> are detailed messages saying:
>>> "the covariance matrix cannot be null"
>>> "the function cannot be null"
>>> "the denominator cannot be null"
>>> etc.
>>> But since any reference can potentially be "null", do you really intend to
>>> have a specific meesage for every object?
>> For these very low level errors, I would be happy with the single
>> message from JVM.
>
> So, shall I remove all checks for "null" (and those items in
> "LocalizedFormats" that are used for reporting it)?
> Should I open a JIRA issue?
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Bill Barker <bi...@verizon.net>.
--------------------------------------------------
From: "Gilles Sadowski" <gi...@harfang.homelinux.org>
Sent: Wednesday, August 04, 2010 2:27 PM
To: <de...@commons.apache.org>
Subject: Re: [Math] Usage of "NullPointerException"
>> > A simpler policy would be to not check for "null" and let the JVM do
>> > it. As
>> > the JVM will do it anyway, it's a redundant check when the reference is
>> > not
>> > null, i.e. most of time (in legitimate usage).
>>
>> This simpler policy seems fine to me.
>> However, it is an important change from previous behaviour.
>
> In practice it is not that important: there are currently only 29
> occurrences of messages referring to "null"; among those only 6 raise a
> NullPointerException (the others throw an IllegalArgumentException).
>
>> > When the usage is wrong, the error is obvious and always the same
>> > ("null
>> > reference") and the "NullPointerException" fully identify the problem.
>> > I
>> > don't see why we should have a localized version of it. Yes, again,
>> > there
>> > are detailed messages saying:
>> > "the covariance matrix cannot be null"
>> > "the function cannot be null"
>> > "the denominator cannot be null"
>> > etc.
>> > But since any reference can potentially be "null", do you really intend
>> > to
>> > have a specific meesage for every object?
>>
>> For these very low level errors, I would be happy with the single
>> message from JVM.
I would be happy with a single message from the JVM. Especially since we
are now inconsistent about when we use the localized version vs. the JVM
version of NPE.
>
> So, shall I remove all checks for "null" (and those items in
> "LocalizedFormats" that are used for reporting it)?
> Should I open a JIRA issue?
>
It looks like we'll need a JIRA for this. Since we have places that
document that it throws IAE on a null parameter, that would be an
incompatible change for 2.2. So they would have to wait for 3.0.
If you want to change the places where we throw a localized NPE, that would
be fine for 2.2 IMHO (my quick spot check only shows BigFraction). Knock
yourself out.
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > A simpler policy would be to not check for "null" and let the JVM do it. As
> > the JVM will do it anyway, it's a redundant check when the reference is not
> > null, i.e. most of time (in legitimate usage).
>
> This simpler policy seems fine to me.
> However, it is an important change from previous behaviour.
In practice it is not that important: there are currently only 29
occurrences of messages referring to "null"; among those only 6 raise a
NullPointerException (the others throw an IllegalArgumentException).
> > When the usage is wrong, the error is obvious and always the same ("null
> > reference") and the "NullPointerException" fully identify the problem. I
> > don't see why we should have a localized version of it. Yes, again, there
> > are detailed messages saying:
> > "the covariance matrix cannot be null"
> > "the function cannot be null"
> > "the denominator cannot be null"
> > etc.
> > But since any reference can potentially be "null", do you really intend to
> > have a specific meesage for every object?
>
> For these very low level errors, I would be happy with the single
> message from JVM.
So, shall I remove all checks for "null" (and those items in
"LocalizedFormats" that are used for reporting it)?
Should I open a JIRA issue?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Usage of "NullPointerException" (Was: Re: svn commit:
r981244 - in /commons/proper/math/trunk/src/main: ...)
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 04/08/2010 15:28, Gilles Sadowski a écrit :
>>>> Why not in the new "exception" package?
>>>> [The aim being to deprecate the old "MathRuntimeException".]
>>>
>>> Sorry for that. I'm still not used to the new package.
>>> Could you look at the various createXxxException factory methods in and
>>> replace them by dedicated exceptions in the new package ? Obviously this
>>> one is used only from one class but the older ones are more heavily used.
>>
>> I've created "MathUnsupportedOperationException" (not committed yet). I was
>> going to create "MathNullPointerException" but then looking at the usage in
>> CM, I noticed that most checks for "null" result in throwing an
>> "IllegalArgumentException"; exceptions to that rule appear in class
>> "BigFraction". The usage should be consistent. I think that it is fine to
>> use "MathIllegalArgumentException" everywhere. In which case I think that
>> that we shouldn't have a "MathNullPointerException" at all (and never throw
>> a "NullPointerException" explicitly from CM, so that when it happens, it
>> will mean that some check is missing somewhere).
>
> A simpler policy would be to not check for "null" and let the JVM do it. As
> the JVM will do it anyway, it's a redundant check when the reference is not
> null, i.e. most of time (in legitimate usage).
This simpler policy seems fine to me.
However, it is an important change from previous behaviour.
> When the usage is wrong, the error is obvious and always the same ("null
> reference") and the "NullPointerException" fully identify the problem. I
> don't see why we should have a localized version of it. Yes, again, there
> are detailed messages saying:
> "the covariance matrix cannot be null"
> "the function cannot be null"
> "the denominator cannot be null"
> etc.
> But since any reference can potentially be "null", do you really intend to
> have a specific meesage for every object?
For these very low level errors, I would be happy with the single
message from JVM.
Luc
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: [Math] Usage of "NullPointerException" (Was: Re: svn commit:
r981244 - in /commons/proper/math/trunk/src/main: ...)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > > Why not in the new "exception" package?
> > > [The aim being to deprecate the old "MathRuntimeException".]
> >
> > Sorry for that. I'm still not used to the new package.
> > Could you look at the various createXxxException factory methods in and
> > replace them by dedicated exceptions in the new package ? Obviously this
> > one is used only from one class but the older ones are more heavily used.
>
> I've created "MathUnsupportedOperationException" (not committed yet). I was
> going to create "MathNullPointerException" but then looking at the usage in
> CM, I noticed that most checks for "null" result in throwing an
> "IllegalArgumentException"; exceptions to that rule appear in class
> "BigFraction". The usage should be consistent. I think that it is fine to
> use "MathIllegalArgumentException" everywhere. In which case I think that
> that we shouldn't have a "MathNullPointerException" at all (and never throw
> a "NullPointerException" explicitly from CM, so that when it happens, it
> will mean that some check is missing somewhere).
A simpler policy would be to not check for "null" and let the JVM do it. As
the JVM will do it anyway, it's a redundant check when the reference is not
null, i.e. most of time (in legitimate usage).
When the usage is wrong, the error is obvious and always the same ("null
reference") and the "NullPointerException" fully identify the problem. I
don't see why we should have a localized version of it. Yes, again, there
are detailed messages saying:
"the covariance matrix cannot be null"
"the function cannot be null"
"the denominator cannot be null"
etc.
But since any reference can potentially be "null", do you really intend to
have a specific meesage for every object?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Math] Usage of "NullPointerException" (Was: Re: svn commit:
r981244 - in /commons/proper/math/trunk/src/main: ...)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > Why not in the new "exception" package?
> > [The aim being to deprecate the old "MathRuntimeException".]
>
> Sorry for that. I'm still not used to the new package.
> Could you look at the various createXxxException factory methods in and
> replace them by dedicated exceptions in the new package ? Obviously this
> one is used only from one class but the older ones are more heavily used.
I've created "MathUnsupportedOperationException" (not committed yet). I was
going to create "MathNullPointerException" but then looking at the usage in
CM, I noticed that most checks for "null" result in throwing an
"IllegalArgumentException"; exceptions to that rule appear in class
"BigFraction". The usage should be consistent. I think that it is fine to
use "MathIllegalArgumentException" everywhere. In which case I think that
that we shouldn't have a "MathNullPointerException" at all (and never throw
a "NullPointerException" explicitly from CM, so that when it happens, it
will mean that some check is missing somewhere).
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r981244 - in /commons/proper/math/trunk/src/main:
java/org/apache/commons/math/ java/org/apache/commons/math/linear/ java/org/apache/commons/math/util/
resources/META-INF/localization/
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 01/08/2010 19:11, Gilles Sadowski a écrit :
> On Sun, Aug 01, 2010 at 03:27:20PM -0000, luc@apache.org wrote:
>> Author: luc
>> Date: Sun Aug 1 15:27:20 2010
>> New Revision: 981244
>>
>> URL: http://svn.apache.org/viewvc?rev=981244&view=rev
>> Log:
>> Added a localized UnsupportedOperationException
>
> Why not in the new "exception" package?
> [The aim being to deprecate the old "MathRuntimeException".]
Sorry for that. I'm still not used to the new package.
Could you look at the various createXxxException factory methods in and
replace them by dedicated exceptions in the new package ? Obviously this
one is used only from one class but the older ones are more heavily used.
Luc
>
>
> Gilles
>
> ---------------------------------------------------------------------
> 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: r981244 - in /commons/proper/math/trunk/src/main:
java/org/apache/commons/math/ java/org/apache/commons/math/linear/
java/org/apache/commons/math/util/ resources/META-INF/localization/
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Aug 01, 2010 at 03:27:20PM -0000, luc@apache.org wrote:
> Author: luc
> Date: Sun Aug 1 15:27:20 2010
> New Revision: 981244
>
> URL: http://svn.apache.org/viewvc?rev=981244&view=rev
> Log:
> Added a localized UnsupportedOperationException
Why not in the new "exception" package?
[The aim being to deprecate the old "MathRuntimeException".]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org