Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
BTW, you can find precedence in the JVM for many methods that throw NPE on null arguments. I am not saying this is the "right way", since such things are subjective and are a matter of design, but many people have concluded it's better. On Tue, Mar 1, 2011 at 9:16 PM, Bill Barker wrote: > > > -Original Message- From: Gilles Sadowski > Sent: Tuesday, March 01, 2011 3:12 PM > To: dev@commons.apache.org > Subject: Re: [Math - 403] Never propagate a "NullPointerException" > resulting from bad usage of the API > > > Hi. >> >> It's a debate that goes on. Josh Bloch in his Effective Java book says >>> NPE >>> is perfectly acceptable for bad arguments. So it really depends on your >>> perspective what an NPE represents. I prefer Josh's opinion but only >>> because >>> every single argument probably creates lots of branch-checking that kills >>> cpu pipelining. >>> >>> > As far as this issue is concerned (for what i have understood) i > >>> believe >>> > that one way to separate NULL(s) that occur from the A.P.I. from > >>> NULL(s) >>> > coming from wrong usage of A.P.I. by a user is the assert technique... >>> > I >>> > didn't know a lot about it but from what i have read it should be >>> > implemented only in the private methods of the A.P.I. Check this link > >>> out: >>> > " >>> > http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";. >>> > Another choice is to create a new class that would check all the > >>> arguments >>> > of every function we are interested in (for example: public >>> > checkArguments(Object... args)) [If i have understood correctly the > >>> purpose >>> > of this issue...]. Any suggestions would be more than welcomed! >>> >> >> NPE is the symptom of a bug. >> Using "NullArgumentException" instead of the standard NPE so that the CM >> exception hierarchy is singly rooted (the root being "MathRuntimeEception" >> in the development version). An advantage is that it is easy to determine >> whether an exception is generated by CM. A drawback is that it is >> non-standard but this is mitigated by the fact that all other exceptions >> are >> also non-standard (e.g. "MathIllegalArgumentException" instead of IAE). >> One has to take into account that we settled on this choice because it >> makes >> it somewhat easier to implement other requirements (namely the >> localization >> of the error messages). It's a compromise (without the localization >> requirement, I would have favoured the standard exceptions). And, apart >> from >> avoiding code duplication, this choice has some "features" (which might be >> construed as advantages or drawbacks, depending on the viewpoint)... >> >> I'm not sure of what you mean by "branch-checking", but I don't think that >> checking for null makes the problem bigger than it would be otherwise, >> since >> CM already checks for many things. >> >> In the end, I'm really not sure what is the best approach for this >> particular case. Personally, I'd be happy that the CM code never checks >> for >> null and let the JVM throw NPE. This would hugely simplify the CM code, >> albeit at the cost of detecting bad usage a little later. IMHO, it is not >> a >> big deal because the bug is that an object is missing somewhere up the >> call >> stack, and it should be corrected there... >> >> > I'm in favor of just letting the JVM throw NPE. Since there is no message > in this case, there is nothing to localize. Using a class to check > arguments is too much work, since the (localized) message "Something was > null" is less than helpful. And assert will be turned off in any reasonably > configured production server so makes the code less readable and adds very > little value. If the null happens because of code in CM (as opposed to user > error), then we'll get a Jira issue, fix it, and add a unit test. If it is > user error, then the stack trace of the NPE will tell the developer what was > wrong in at least 95% of the cases. > > > > > Of course, this would mean that MATH-403 should be dropped, the >> "NullArgumentException" class removed, and the policy changed to: "Never >> check for null references". >> >> >> Best, >> Gilles >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
The recognised standard in the JDK is NPE on invalid null input. I have never overly liked this, but conform to it for JSR-310/ThreeTen. I use IAE in other projects which are higher up the stack. Whether [math] is low or high level may determine the choice you make. Personally, I don't use NullArgEx, as it is never an exception that the user should catch. The message of IAE is sufficiently good to remove the need for NullArgEx. Thus in my opinion, [math] would be better off without NullArgEx (as it adds no real value). However, with this, and other exception issues, the truth is that for [math] its mostly a matter of taste. The value in [math] is in the algorithms, not in whether the exceptions are any good or not. As such, I would advise worrying less about exceptions, and more about maths. If there is an exception decision, just try to follow the modern JDK examples where possible (as it reduces discussion here). Stephen On 2 March 2011 08:20, Paul Benedict wrote: > BTW, you can find precedence in the JVM for many methods that throw NPE on > null arguments. I am not saying this is the "right way", since such things > are subjective and are a matter of design, but many people have concluded > it's better. > > On Tue, Mar 1, 2011 at 9:16 PM, Bill Barker wrote: > >> >> >> -Original Message- From: Gilles Sadowski >> Sent: Tuesday, March 01, 2011 3:12 PM >> To: dev@commons.apache.org >> Subject: Re: [Math - 403] Never propagate a "NullPointerException" >> resulting from bad usage of the API >> >> >> Hi. >>> >>> It's a debate that goes on. Josh Bloch in his Effective Java book says NPE is perfectly acceptable for bad arguments. So it really depends on your perspective what an NPE represents. I prefer Josh's opinion but only because every single argument probably creates lots of branch-checking that kills cpu pipelining. > As far as this issue is concerned (for what i have understood) i > believe > that one way to separate NULL(s) that occur from the A.P.I. from > NULL(s) > coming from wrong usage of A.P.I. by a user is the assert technique... > I > didn't know a lot about it but from what i have read it should be > implemented only in the private methods of the A.P.I. Check this link > out: > " > http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";. > Another choice is to create a new class that would check all the > arguments > of every function we are interested in (for example: public > checkArguments(Object... args)) [If i have understood correctly the > purpose > of this issue...]. Any suggestions would be more than welcomed! >>> >>> NPE is the symptom of a bug. >>> Using "NullArgumentException" instead of the standard NPE so that the CM >>> exception hierarchy is singly rooted (the root being "MathRuntimeEception" >>> in the development version). An advantage is that it is easy to determine >>> whether an exception is generated by CM. A drawback is that it is >>> non-standard but this is mitigated by the fact that all other exceptions >>> are >>> also non-standard (e.g. "MathIllegalArgumentException" instead of IAE). >>> One has to take into account that we settled on this choice because it >>> makes >>> it somewhat easier to implement other requirements (namely the >>> localization >>> of the error messages). It's a compromise (without the localization >>> requirement, I would have favoured the standard exceptions). And, apart >>> from >>> avoiding code duplication, this choice has some "features" (which might be >>> construed as advantages or drawbacks, depending on the viewpoint)... >>> >>> I'm not sure of what you mean by "branch-checking", but I don't think that >>> checking for null makes the problem bigger than it would be otherwise, >>> since >>> CM already checks for many things. >>> >>> In the end, I'm really not sure what is the best approach for this >>> particular case. Personally, I'd be happy that the CM code never checks >>> for >>> null and let the JVM throw NPE. This would hugely simplify the CM code, >>> albeit at the cost of detecting bad usage a little later. IMHO, it is not >>> a >>> big deal because the bug is that an object is missing somewhere up the >>> call >>> stack, and it should be corrected there... >>> >>> >> I'm in favor of just letting the JVM throw NPE. Since there is no message >> in this case, there is nothing to localize. Using a class to check >> arguments is too much work, since the (localized) message "Something was >> null" is less than helpful. And assert will be turned off in any reasonably >> configured production server so makes the code less readable and adds very >> little value. If the null happens because of code in CM (as opposed to user >> error), then we'll get a Jira issue, fix it, and add a unit test. If it is >> user error, then the stack trace of the NPE will tell the developer what wa
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-scxml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 115 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-scxml-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html Work Name: build_apache-commons_commons-scxml-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/scxml] M2_HOME: /opt/maven2 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.393 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.17 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.791 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.312 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.276 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.376 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Wed Mar 02 10:07:33 UTC 2011 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06000602032011, vmgump.apache.org:vmgump:06000602032011 Gump E-mail Identifier (unique wit
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
> > [...] > > I'm in favor of just letting the JVM throw NPE. Since there is no > message in this case, there is nothing to localize. Using a class > to check arguments is too much work, since the (localized) message > "Something was null" is less than helpful. And assert will be > turned off in any reasonably configured production server so makes > the code less readable and adds very little value. If the null > happens because of code in CM (as opposed to user error), then we'll > get a Jira issue, fix it, and add a unit test. If it is user error, > then the stack trace of the NPE will tell the developer what was > wrong in at least 95% of the cases. That was my first line of arguments, a long time ago. But there was no agreement mainly because of the will to retain the possibility of localizing the message, even for NPE (i.e. one should be able to supply a "Localizable" argument to the constructor of "NullArgumentException"). A second counter-argument was that in a certain use-case, no stack trace is available. Best, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 115 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.161 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Wed Mar 02 10:49:05 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
> The recognised standard in the JDK is NPE on invalid null input. > > I have never overly liked this, but conform to it for JSR-310/ThreeTen. > > I use IAE in other projects which are higher up the stack. Whether > [math] is low or high level may determine the choice you make. I've always heard that CM is "low"-level; and this serves as the basis of many arguments (e.g. the "no-dependency" one). However I think that, in CM, the line between low- and high-level is blurred when some features are concerned (e.g. IMO localization does not belong in a low-level library). > Personally, I don't use NullArgEx, as it is never an exception that > the user should catch. The message of IAE is sufficiently good to > remove the need for NullArgEx. Thus in my opinion, [math] would be > better off without NullArgEx (as it adds no real value). I guess that not everyone would agree with the "never". An application requirement might be that only a certain kind of exception is expected. Thus calls to CM are wrapped and every exception that comes out is turned into one of the "allowed" exceptions. I don't discuss whether it's good or bad programming style, I just mention that it happens. > However, with this, and other exception issues, the truth is that for > [math] its mostly a matter of taste. The value in [math] is in the > algorithms, not in whether the exceptions are any good or not. As > such, I would advise worrying less about exceptions, and more about > maths. If there is an exception decision, just try to follow the > modern JDK examples where possible (as it reduces discussion here). My viewpoint is that an exception is, in essence, a low-level object. It should just remain a very convenient way to communicate failure from a lower to upper layers of code. My revamping the CM's exceptions aimed at regaining the straightforward usage of standard exceptions (i.e. a direct call to "new" for constructing an exception that conveys the unadorned reason for the failure). The compromise we had reached was about keeping the localization feature, which in turn implied a departure from the standard exceptions in order to avoid code duplication. I consider this more important than using the standard exceptions hierarchy because, in CM, most exceptions are not recoverable anyway and they mainly serve by showing a failure message (i.e. at that point, whether an object is an instance of this or that class does not matter anymore). The discussion flared up when we started arguing on semantical issues that (IMHO) exceptions were not designed to handle and cannot enforce. I'm not going to re-state all the arguments once again; I'll simply quote you: "The value in [math] is in the algorithms, not in whether the exceptions are any good or not." I totally agree with the first statement, of course. The second part does not add (nor subtract) any value to it; it's unrelated. In my view, the exceptions are good if they allow to easily track down bugs (be they in CM or in user code). Accordingly they must precisely point to the source of the problem (in the code) and not try to outguess the user (as to what it should mean for him). Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1076181 - in /commons/sandbox/digester3/trunk/src/main/java/org/apache/commons/digester3: Digester.java internal/DigesterImpl.java rule/CallMethodRule.java rule/CallParamRule.java rul
Hi Simon,
simonetrip...@apache.org wrote:
[snip]
> @@ -335,7 +335,7 @@ public interface Digester extends Conten
> *
> * @param object The new object
> */
> -void pushParams(Object object);
> +void pushParams(Object[] object);
>
> /**
> * Pop the top object off of the parameters stack, and return it.
> If there are
[snip]
> @@ -423,7 +423,7 @@ public final class DigesterImpl implemen
> /**
> * {@inheritDoc}
> */
> -public void pushParams(Object object) {
> +public void pushParams(Object[] object) {
> if (this.log.isTraceEnabled()) {
> this.log.trace("Pushing params");
> }
[snip]
Good candidates for varargs ... :-)
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
On 2 March 2011 08:20, Paul Benedict wrote: > BTW, you can find precedence in the JVM for many methods that throw NPE on > null arguments. I am not saying this is the "right way", since such things > are subjective and are a matter of design, but many people have concluded > it's better. If the NPE would not be detected until the method has done some other work, then I can seem why one might want to detect it earlier. And the line number may be insufficient to identify the source of the NPE - there could be several de-references in a single line. > On Tue, Mar 1, 2011 at 9:16 PM, Bill Barker wrote: > >> >> >> -Original Message- From: Gilles Sadowski >> Sent: Tuesday, March 01, 2011 3:12 PM >> To: dev@commons.apache.org >> Subject: Re: [Math - 403] Never propagate a "NullPointerException" >> resulting from bad usage of the API >> >> >> Hi. >>> >>> It's a debate that goes on. Josh Bloch in his Effective Java book says NPE is perfectly acceptable for bad arguments. So it really depends on your perspective what an NPE represents. I prefer Josh's opinion but only because every single argument probably creates lots of branch-checking that kills cpu pipelining. > As far as this issue is concerned (for what i have understood) i > believe > that one way to separate NULL(s) that occur from the A.P.I. from > NULL(s) > coming from wrong usage of A.P.I. by a user is the assert technique... > I > didn't know a lot about it but from what i have read it should be > implemented only in the private methods of the A.P.I. Check this link > out: > " > http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";. > Another choice is to create a new class that would check all the > arguments > of every function we are interested in (for example: public > checkArguments(Object... args)) [If i have understood correctly the > purpose > of this issue...]. Any suggestions would be more than welcomed! >>> >>> NPE is the symptom of a bug. >>> Using "NullArgumentException" instead of the standard NPE so that the CM >>> exception hierarchy is singly rooted (the root being "MathRuntimeEception" >>> in the development version). An advantage is that it is easy to determine >>> whether an exception is generated by CM. A drawback is that it is >>> non-standard but this is mitigated by the fact that all other exceptions >>> are >>> also non-standard (e.g. "MathIllegalArgumentException" instead of IAE). >>> One has to take into account that we settled on this choice because it >>> makes >>> it somewhat easier to implement other requirements (namely the >>> localization >>> of the error messages). It's a compromise (without the localization >>> requirement, I would have favoured the standard exceptions). And, apart >>> from >>> avoiding code duplication, this choice has some "features" (which might be >>> construed as advantages or drawbacks, depending on the viewpoint)... >>> >>> I'm not sure of what you mean by "branch-checking", but I don't think that >>> checking for null makes the problem bigger than it would be otherwise, >>> since >>> CM already checks for many things. >>> >>> In the end, I'm really not sure what is the best approach for this >>> particular case. Personally, I'd be happy that the CM code never checks >>> for >>> null and let the JVM throw NPE. This would hugely simplify the CM code, >>> albeit at the cost of detecting bad usage a little later. IMHO, it is not >>> a >>> big deal because the bug is that an object is missing somewhere up the >>> call >>> stack, and it should be corrected there... >>> >>> >> I'm in favor of just letting the JVM throw NPE. Since there is no message >> in this case, there is nothing to localize. Using a class to check >> arguments is too much work, since the (localized) message "Something was >> null" is less than helpful. And assert will be turned off in any reasonably >> configured production server so makes the code less readable and adds very >> little value. If the null happens because of code in CM (as opposed to user >> error), then we'll get a Jira issue, fix it, and add a unit test. If it is >> user error, then the stack trace of the NPE will tell the developer what was >> wrong in at least 95% of the cases. >> >> >> >> >> Of course, this would mean that MATH-403 should be dropped, the >>> "NullArgumentException" class removed, and the policy changed to: "Never >>> check for null references". >>> >>> >>> Best, >>> Gilles >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > ---
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
> > BTW, you can find precedence in the JVM for many methods that throw NPE on > > null arguments. I am not saying this is the "right way", since such things > > are subjective and are a matter of design, but many people have concluded > > it's better. > > If the NPE would not be detected until the method has done some other > work, then I can seem why one might want to detect it earlier. > > And the line number may be insufficient to identify the source of the > NPE - there could be several de-references in a single line. This is the trade-off which I had mentioned here: > >>> In the end, I'm really not sure what is the best approach for this > >>> particular case. Personally, I'd be happy that the CM code never checks > >>> for > >>> null and let the JVM throw NPE. This would hugely simplify the CM code, > >>> albeit at the cost of detecting bad usage a little later. IMHO, it is not > >>> a > >>> big deal because the bug is that an object is missing somewhere up the > >>> call > >>> stack, and it should be corrected there... Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
On 2 March 2011 12:50, Gilles Sadowski wrote: >> > BTW, you can find precedence in the JVM for many methods that throw NPE on >> > null arguments. I am not saying this is the "right way", since such things >> > are subjective and are a matter of design, but many people have concluded >> > it's better. >> >> If the NPE would not be detected until the method has done some other >> work, then I can seem why one might want to detect it earlier. The above is the trade-off. >> And the line number may be insufficient to identify the source of the >> NPE - there could be several de-references in a single line. > > This is the trade-off which I had mentioned here: Not really ... >> >>> In the end, I'm really not sure what is the best approach for this >> >>> particular case. Personally, I'd be happy that the CM code never checks >> >>> for >> >>> null and let the JVM throw NPE. This would hugely simplify the CM code, >> >>> albeit at the cost of detecting bad usage a little later. IMHO, it is not >> >>> a >> >>> big deal because the bug is that an object is missing somewhere up the >> >>> call >> >>> stack, and it should be corrected there... > .. it may be impossible to determine the true cause of the NPE in some cases. So in some cases, it makes sense to check for NPE at the start. > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
Le 02/03/2011 12:37, Gilles Sadowski a écrit : >> The recognised standard in the JDK is NPE on invalid null input. >> >> I have never overly liked this, but conform to it for JSR-310/ThreeTen. >> >> I use IAE in other projects which are higher up the stack. Whether >> [math] is low or high level may determine the choice you make. > > I've always heard that CM is "low"-level; and this serves as the basis of > many arguments (e.g. the "no-dependency" one). Yes. > However I think that, in CM, the line between low- and high-level is blurred > when some features are concerned (e.g. IMO localization does not belong in a > low-level library). It is a requirement for many libraries. In fact I even saw this requirement being explicitly written in the specifications of an official public Request For Proposal for a project concerning Apache Commons Math. > >> Personally, I don't use NullArgEx, as it is never an exception that >> the user should catch. The message of IAE is sufficiently good to >> remove the need for NullArgEx. Thus in my opinion, [math] would be >> better off without NullArgEx (as it adds no real value). > > I guess that not everyone would agree with the "never". An application > requirement might be that only a certain kind of exception is expected. > Thus calls to CM are wrapped and every exception that comes out is turned > into one of the "allowed" exceptions. > I don't discuss whether it's good or bad programming style, I just mention > that it happens. > >> However, with this, and other exception issues, the truth is that for >> [math] its mostly a matter of taste. The value in [math] is in the >> algorithms, not in whether the exceptions are any good or not. As >> such, I would advise worrying less about exceptions, and more about >> maths. If there is an exception decision, just try to follow the >> modern JDK examples where possible (as it reduces discussion here). > > My viewpoint is that an exception is, in essence, a low-level object. It > should just remain a very convenient way to communicate failure from a lower > to upper layers of code. My revamping the CM's exceptions aimed at regaining > the straightforward usage of standard exceptions (i.e. a direct call to > "new" for constructing an exception that conveys the unadorned reason for > the failure). > The compromise we had reached was about keeping the localization feature, > which in turn implied a departure from the standard exceptions in order to > avoid code duplication. Not really. Typically the 2.1 method MathException.createNullPointerException (and the other similar ones) did achieve using both the standard exception and the localization at the same time. So I would say localization and exception hierarchy are completely orthogonal features. > I consider this more important than using the > standard exceptions hierarchy because, in CM, most exceptions are not > recoverable anyway and they mainly serve by showing a failure message (i.e. > at that point, whether an object is an instance of this or that class does > not matter anymore). > > The discussion flared up when we started arguing on semantical issues that > (IMHO) exceptions were not designed to handle and cannot enforce. I'm not > going to re-state all the arguments once again; I'll simply quote you: > "The value in [math] is in the algorithms, not in whether the exceptions >are any good or not." > I totally agree with the first statement, of course. Fine! I think we all do agree on this. > The second part does > not add (nor subtract) any value to it; it's unrelated. In my view, the > exceptions are good if they allow to easily track down bugs (be they in CM > or in user code). Accordingly they must precisely point to the source of the > problem (in the code) and not try to outguess the user (as to what it > should mean for him). So can we try to conclude this part and go back to algorithms ? Rereading the past threads about this, including the advices from non-math people, I would propose the following consensus : 1) use only unchecked exception (i.e. confirm the switch started in trunk) 2) keep localization 3) don't put all exceptions in a dedicated exception package (but the general exceptions used everywhere could go there) 4) put specific exceptions in the package they are triggered (for example ODE, linear ...) 5) use a small hierarchy backed by an implementation of the principle of exception context as per [lang] to provide state information and allow extension by users calling addValue(label, value), a typical example could be one ConvergenceException class and different labels/values for count exceeded or NaN/Infinity appearing 6) don't provide any top-level exception for errors occurring in user-provided code (for solvers, ode, matrix visitors ...) but ask them in documentation to use their own unchecked exception that [math] will never see (i.e. remove FunctionEvaluationException, Der
Re: svn commit: r1076181 - in /commons/sandbox/digester3/trunk/src/main/java/org/apache/commons/digester3: Digester.java internal/DigesterImpl.java rule/CallMethodRule.java rule/CallParamRule.java rul
Hi Jorg,
indeed, thanks for your feedback, very appreciated!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Mar 2, 2011 at 1:17 PM, Jörg Schaible
wrote:
> Hi Simon,
>
> simonetrip...@apache.org wrote:
>
> [snip]
>
>> @@ -335,7 +335,7 @@ public interface Digester extends Conten
>> *
>> * @param object The new object
>> */
>> - void pushParams(Object object);
>> + void pushParams(Object[] object);
>>
>> /**
>> * Pop the top object off of the parameters stack, and return it.
>> If there are
>
> [snip]
>
>> @@ -423,7 +423,7 @@ public final class DigesterImpl implemen
>> /**
>> * {@inheritDoc}
>> */
>> - public void pushParams(Object object) {
>> + public void pushParams(Object[] object) {
>> if (this.log.isTraceEnabled()) {
>> this.log.trace("Pushing params");
>> }
>
> [snip]
>
> Good candidates for varargs ... :-)
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
On Wed, Mar 02, 2011 at 01:11:48PM +, sebb wrote: > On 2 March 2011 12:50, Gilles Sadowski wrote: > >> > BTW, you can find precedence in the JVM for many methods that throw NPE > >> > on > >> > null arguments. I am not saying this is the "right way", since such > >> > things > >> > are subjective and are a matter of design, but many people have concluded > >> > it's better. > >> > >> If the NPE would not be detected until the method has done some other > >> work, then I can seem why one might want to detect it earlier. > > The above is the trade-off. Hence you say that the programmer can choose to test or not. Indeed this is already how it is done in CM: Sometimes there is a check and sometimes not. So we'd have to state a guideline such that "If the NPE would not be detected until the method has done some other work, checks for null references should be done at start." And also that, if the reference is null, a (standard) NPE must be thrown (without a message, because it wouldn't be localized). But how much work warrants an additional check? What if there is no "other work" in the original code but someone adds some later on (and forget to add the check)? Overall, I'd think that the advantage is not worth the complication. > >> And the line number may be insufficient to identify the source of the > >> NPE - there could be several de-references in a single line. > > > > This is the trade-off which I had mentioned here: > > Not really ... > > >> >>> In the end, I'm really not sure what is the best approach for this > >> >>> particular case. Personally, I'd be happy that the CM code never checks > >> >>> for > >> >>> null and let the JVM throw NPE. This would hugely simplify the CM code, > >> >>> albeit at the cost of detecting bad usage a little later. IMHO, it is > >> >>> not > >> >>> a > >> >>> big deal because the bug is that an object is missing somewhere up the > >> >>> call > >> >>> stack, and it should be corrected there... > > > > .. it may be impossible to determine the true cause of the NPE in some cases. Even when re-writing the statements on multiple lines for debugging purposes? > So in some cases, it makes sense to check for NPE at the start. I didn't say otherwise. But we might want to trade-off the possibility of _easily_ spotting the failure (this is what I meant by "at the cost of detecting bad usage a little later") for improved performance. I still favour the simplest option: no checks for null whatsoever. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
On 3/2/11 8:32 AM, Luc Maisonobe wrote: > Le 02/03/2011 12:37, Gilles Sadowski a écrit : >>> The recognised standard in the JDK is NPE on invalid null input. >>> >>> I have never overly liked this, but conform to it for JSR-310/ThreeTen. >>> >>> I use IAE in other projects which are higher up the stack. Whether >>> [math] is low or high level may determine the choice you make. >> I've always heard that CM is "low"-level; and this serves as the basis of >> many arguments (e.g. the "no-dependency" one). > Yes. > >> However I think that, in CM, the line between low- and high-level is blurred >> when some features are concerned (e.g. IMO localization does not belong in a >> low-level library). > It is a requirement for many libraries. In fact I even saw this > requirement being explicitly written in the specifications of an > official public Request For Proposal for a project concerning Apache > Commons Math. > >>> Personally, I don't use NullArgEx, as it is never an exception that >>> the user should catch. The message of IAE is sufficiently good to >>> remove the need for NullArgEx. Thus in my opinion, [math] would be >>> better off without NullArgEx (as it adds no real value). >> I guess that not everyone would agree with the "never". An application >> requirement might be that only a certain kind of exception is expected. >> Thus calls to CM are wrapped and every exception that comes out is turned >> into one of the "allowed" exceptions. >> I don't discuss whether it's good or bad programming style, I just mention >> that it happens. >> >>> However, with this, and other exception issues, the truth is that for >>> [math] its mostly a matter of taste. The value in [math] is in the >>> algorithms, not in whether the exceptions are any good or not. As >>> such, I would advise worrying less about exceptions, and more about >>> maths. If there is an exception decision, just try to follow the >>> modern JDK examples where possible (as it reduces discussion here). >> My viewpoint is that an exception is, in essence, a low-level object. It >> should just remain a very convenient way to communicate failure from a lower >> to upper layers of code. My revamping the CM's exceptions aimed at regaining >> the straightforward usage of standard exceptions (i.e. a direct call to >> "new" for constructing an exception that conveys the unadorned reason for >> the failure). >> The compromise we had reached was about keeping the localization feature, >> which in turn implied a departure from the standard exceptions in order to >> avoid code duplication. > Not really. Typically the 2.1 method > MathException.createNullPointerException (and the other similar ones) > did achieve using both the standard exception and the localization at > the same time. So I would say localization and exception hierarchy are > completely orthogonal features. > >> I consider this more important than using the >> standard exceptions hierarchy because, in CM, most exceptions are not >> recoverable anyway and they mainly serve by showing a failure message (i.e. >> at that point, whether an object is an instance of this or that class does >> not matter anymore). >> >> The discussion flared up when we started arguing on semantical issues that >> (IMHO) exceptions were not designed to handle and cannot enforce. I'm not >> going to re-state all the arguments once again; I'll simply quote you: >> "The value in [math] is in the algorithms, not in whether the exceptions >>are any good or not." >> I totally agree with the first statement, of course. > Fine! I think we all do agree on this. > >> The second part does >> not add (nor subtract) any value to it; it's unrelated. In my view, the >> exceptions are good if they allow to easily track down bugs (be they in CM >> or in user code). Accordingly they must precisely point to the source of the >> problem (in the code) and not try to outguess the user (as to what it >> should mean for him). > So can we try to conclude this part and go back to algorithms ? > > Rereading the past threads about this, including the advices from > non-math people, I would propose the following consensus : > > 1) use only unchecked exception > (i.e. confirm the switch started in trunk) +0 - move on > 2) keep localization +1 > 3) don't put all exceptions in a dedicated exception package > (but the general exceptions used everywhere could go there) +1 > 4) put specific exceptions in the package they are triggered > (for example ODE, linear ...) +1 > 5) use a small hierarchy backed by an implementation of the principle > of exception context as per [lang] to provide state information > and allow extension by users calling addValue(label, value), > a typical example could be one ConvergenceException class and > different labels/values for count exceeded or NaN/Infinity appearing Not sure exactly what is meant here. I don't think it is best to devolve all exception context into dynamic name/value pa
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
I agree with this view. It would help the developer who uses CM if the
library told him/her what they did wrong ("argument 'foo' cannot be
null") instead of a simple exception thrown message
("NullPointerException thrown at line nnn of class Xyz").
-Adrian
On 3/2/2011 3:37 AM, Gilles Sadowski wrote:
In my view, the
exceptions are good if they allow to easily track down bugs (be they in CM
or in user code). Accordingly they must precisely point to the source of the
problem (in the code) and not try to outguess the user (as to what it
should mean for him).
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
I neglected to mention that Commons Math *should* document what exceptions
are to be expected. If a method is designed to throw NPE because of a null
argument (whether through explicit checking or not), @throws should mention
that.
Paul
On Wed, Mar 2, 2011 at 10:36 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
> I agree with this view. It would help the developer who uses CM if the
> library told him/her what they did wrong ("argument 'foo' cannot be null")
> instead of a simple exception thrown message ("NullPointerException thrown
> at line nnn of class Xyz").
>
> -Adrian
>
>
> On 3/2/2011 3:37 AM, Gilles Sadowski wrote:
>
>> In my view, the
>> exceptions are good if they allow to easily track down bugs (be they in CM
>> or in user code). Accordingly they must precisely point to the source of
>> the
>> problem (in the code) and not try to outguess the user (as to what it
>> should mean for him).
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
I consider it sufficient (preferable) to do the following:
@param foo the foo, not null
Where the ", not null" implies NPE when a null is passed in (document
once in the overview javadoc if you feel necessary). This approach is
easier to transfer to a @NotNull annotation in the future (or the
proper language solution of nullable types!)
Stephen
On 2 March 2011 16:50, Paul Benedict wrote:
> I neglected to mention that Commons Math *should* document what exceptions
> are to be expected. If a method is designed to throw NPE because of a null
> argument (whether through explicit checking or not), @throws should mention
> that.
>
> Paul
>
> On Wed, Mar 2, 2011 at 10:36 AM, Adrian Crum <
> adrian.c...@sandglass-software.com> wrote:
>
>> I agree with this view. It would help the developer who uses CM if the
>> library told him/her what they did wrong ("argument 'foo' cannot be null")
>> instead of a simple exception thrown message ("NullPointerException thrown
>> at line nnn of class Xyz").
>>
>> -Adrian
>>
>>
>> On 3/2/2011 3:37 AM, Gilles Sadowski wrote:
>>
>>> In my view, the
>>> exceptions are good if they allow to easily track down bugs (be they in CM
>>> or in user code). Accordingly they must precisely point to the source of
>>> the
>>> problem (in the code) and not try to outguess the user (as to what it
>>> should mean for him).
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Apache Commons Math 2.2 released
The Apache Commons team is pleased to announce the release of version 2.2 of Commons Math. Commons Math is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not available in the Java programming language or Commons Lang. Version 2.2 is primarily a maintenance release, but it also includes new features and enhancements. Users of version 2.1 are encouraged to upgrade to 2.2, as this release includes some important bug fixes. This release includes some minor API compatibility breaks with version 2.1. See the detailed list of changes included in the release notes for full description of all API changes, bug fixes and enhancements. Source and binary distributions are available for download from the Apache Commons Math download site: http://commons.apache.org/math/download_math.cgi Please verify signatures using the KEYS file available at the above location when downloading the release. For more information on Apache Commons Math, visit the Math home page: http://commons.apache.org/math/ Feedback, suggestions for improvement or bug reports are welcome via the "Mailing Lists" and "Issue Tracking" links here: http://commons.apache.org/math/project-info.html Luc Maisonobe - On behalf of the Apache Commons community - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Net - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=3548&projectId=107 Build statistics: State: Failed Previous State: Ok Started at: Wed 2 Mar 2011 18:20:39 + Finished at: Wed 2 Mar 2011 18:20:51 + Total time: 12s Build Trigger: Schedule Build Number: 42 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_22 Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-27-server" arch: "amd64" Family: "unix" SCM Changes: Changed: sebb @ Wed 2 Mar 2011 17:28:37 + Comment: Ensure data connection is closed regardless Files changed: /commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClient.java ( 1076306 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
Hello. > >> The recognised standard in the JDK is NPE on invalid null input. > >> > >> I have never overly liked this, but conform to it for JSR-310/ThreeTen. > >> > >> I use IAE in other projects which are higher up the stack. Whether > >> [math] is low or high level may determine the choice you make. > > > > I've always heard that CM is "low"-level; and this serves as the basis of > > many arguments (e.g. the "no-dependency" one). > > Yes. > > > However I think that, in CM, the line between low- and high-level is blurred > > when some features are concerned (e.g. IMO localization does not belong in a > > low-level library). > > It is a requirement for many libraries. In fact I even saw this > requirement being explicitly written in the specifications of an > official public Request For Proposal for a project concerning Apache > Commons Math. IIRC, one of your clients required localization. But if the majority of the opinions expressed on this ML were any sign, there wouldn't be a localization feature in CM. Now, I'm not advocating to remove it (in the previous discussion, in reply to people who said it was unnecessary, I stated that it should be treated as a requirement). I still don't like the whole idea, but the implementation has much improved (from the situation where the pattern strings were duplicated in every exception raised). The new hierarchy was partly an outcome of this improvement; and, since it was another requirement to have very detailed error messages, I had proposed to have a hierarchy of stateful exception (because I find it more convenient to read a more specific exception name in the stack trace rather than a plain "IllegalArgumentException" with a long message). Out of curiosity, where can I read that "Request For Proposal"? > >> Personally, I don't use NullArgEx, as it is never an exception that > >> the user should catch. The message of IAE is sufficiently good to > >> remove the need for NullArgEx. Thus in my opinion, [math] would be > >> better off without NullArgEx (as it adds no real value). > > > > I guess that not everyone would agree with the "never". An application > > requirement might be that only a certain kind of exception is expected. > > Thus calls to CM are wrapped and every exception that comes out is turned > > into one of the "allowed" exceptions. > > I don't discuss whether it's good or bad programming style, I just mention > > that it happens. > > > >> However, with this, and other exception issues, the truth is that for > >> [math] its mostly a matter of taste. The value in [math] is in the > >> algorithms, not in whether the exceptions are any good or not. As > >> such, I would advise worrying less about exceptions, and more about > >> maths. If there is an exception decision, just try to follow the > >> modern JDK examples where possible (as it reduces discussion here). > > > > My viewpoint is that an exception is, in essence, a low-level object. It > > should just remain a very convenient way to communicate failure from a lower > > to upper layers of code. My revamping the CM's exceptions aimed at regaining > > the straightforward usage of standard exceptions (i.e. a direct call to > > "new" for constructing an exception that conveys the unadorned reason for > > the failure). > > The compromise we had reached was about keeping the localization feature, > > which in turn implied a departure from the standard exceptions in order to > > avoid code duplication. > > Not really. Typically the 2.1 method > MathException.createNullPointerException (and the other similar ones) > did achieve using both the standard exception and the localization at > the same time. No, that implementation is not "straightforward usage". This factory is unwieldy (and it is an abuse of the "Factory" design pattern). I'm not going to repeat all the arguments against it; just compare the same "throw" statements "before" (release 2.2) and "after" (trunk)... > So I would say localization and exception hierarchy are > completely orthogonal features. "Localization" complicates everything, thus also the exceptions (especially so in CM, because localization is used there). But localization is not even the main problem, it was the attempt to replace a language construct (the exception) by a series of strings (or now enums), many of them were duplicates (indeed, there are already so many of them that when a "new" message was needed, it seemed that it was added without thoroughly checking whether an existing one could be reused). The new exceptions were also aimed at relieving this problem. > > I consider this more important than using the > > standard exceptions hierarchy because, in CM, most exceptions are not > > recoverable anyway and they mainly serve by showing a failure message (i.e. > > at that point, whether an object is an instance of this or that class does > > not matter anymore). > > > > The discussion flared up when we started arguing on semantical issues that > >
Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
I believe that the majority of exceptions should be in the same package and not to under different ones... > >>because most exceptions are general and thus I don't see the benefit of > >>scattering the remaining few among several packages. > +1 for the proposal of Gilles > 6) don't provide any top-level exception for errors occurring in > > user-provided code (for solvers, ode, matrix visitors ...) but > > ask them in documentation to use their own unchecked exception > > that [math] will never see (i.e. remove FunctionEvaluationException, > > DerivativeException, MatrixVisitorException) > > +1 for the one of Luc > I'm not sure for NullPointer/NullArgument. Perhaps our own > > NullArgumentException with the [lang] exception context principle would > > be fine. I doubt we should check everything by ourselves (it would be a > > real performance killer), so whatever we choose there will be untracked > > NPE. We should check some arguments where it makes sense, which is what > > we already do at some places. > > +1 for dropping "NullArgumentException" and letting the JVM raise NPE. > +1 to this one Also i think that we should check for some exceptions that are not covered by those which have been implemented so far (for example when we have two numbers 'a' and 'b' and 'a' should always be greater than 'b'...). In this case we should implement them... And of course, to erase all those exceptions for which no 'throw' clause exists as Gilles said. Friendly, Giannakopoulos Michael
Re: svn commit: r1076446 - in /commons/sandbox/functor/trunk/src: main/java/org/apache/commons/functor/core/collection/FilteredIterable.java test/java/org/apache/commons/functor/core/collection/TestFi
On 2 March 2011 22:55, wrote:
> Author: mbenson
> Date: Wed Mar 2 22:55:02 2011
> New Revision: 1076446
>
> URL: http://svn.apache.org/viewvc?rev=1076446&view=rev
> Log:
> add FilteredIterable
>
> Added:
>
> commons/sandbox/functor/trunk/src/main/java/org/apache/commons/functor/core/collection/FilteredIterable.java
> (with props)
>
> commons/sandbox/functor/trunk/src/test/java/org/apache/commons/functor/core/collection/TestFilteredIterable.java
> (with props)
>
> Added:
> commons/sandbox/functor/trunk/src/main/java/org/apache/commons/functor/core/collection/FilteredIterable.java
> URL:
> http://svn.apache.org/viewvc/commons/sandbox/functor/trunk/src/main/java/org/apache/commons/functor/core/collection/FilteredIterable.java?rev=1076446&view=auto
> ==
> ---
> commons/sandbox/functor/trunk/src/main/java/org/apache/commons/functor/core/collection/FilteredIterable.java
> (added)
> +++
> commons/sandbox/functor/trunk/src/main/java/org/apache/commons/functor/core/collection/FilteredIterable.java
> Wed Mar 2 22:55:02 2011
> @@ -0,0 +1,172 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.commons.functor.core.collection;
> +
> +import java.util.Collections;
> +import java.util.Iterator;
> +
> +import org.apache.commons.functor.UnaryFunction;
> +import org.apache.commons.functor.UnaryPredicate;
> +import org.apache.commons.functor.core.IsInstance;
> +import org.apache.commons.functor.core.composite.UnaryAnd;
> +
> +/**
> + * Adds a fluent filtering API to any {@link Iterable}.
> + *
> + * @version $Revision$ $Date$
> + *
> + * @param
> + */
> +public class FilteredIterable implements Iterable {
> + @SuppressWarnings({ "rawtypes", "unchecked" })
> + // type irrelevant for empty instance
> + private static final FilteredIterable EMPTY = new
> FilteredIterable(Collections.EMPTY_LIST) {
BTW, using Collections.emptyList() instead should allow the @Suppress
tag to be removed.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1076446 - in /commons/sandbox/functor/trunk/src: main/java/org/apache/commons/functor/core/collection/FilteredIterable.java test/java/org/apache/commons/functor/core/collection/TestFi
On Mar 2, 2011, at 6:19 PM, sebb wrote:
> On 2 March 2011 22:55, wrote:
>> Author: mbenson
>> Date: Wed Mar 2 22:55:02 2011
>> New Revision: 1076446
>>
>> URL: http://svn.apache.org/viewvc?rev=1076446&view=rev
>> Log:
>> add FilteredIterable
[SNIP]
>> +public class FilteredIterable implements Iterable {
>> +@SuppressWarnings({ "rawtypes", "unchecked" })
>> +// type irrelevant for empty instance
>> +private static final FilteredIterable EMPTY = new
>> FilteredIterable(Collections.EMPTY_LIST) {
>
> BTW, using Collections.emptyList() instead should allow the @Suppress
> tag to be removed.
>
Except that the local instance is itself a raw instance of the containing
parameterized type. ;)
Matt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[site] release pain
The http://commons.apache.org/releases/prepare.html site seems to imply that the latest way to build the zip/tar.gzs is with: mvn -Prc -DcreateChecksum=true install Running that, I don't get what I'd expect. Thought I'd report that. For now I'm going to use assembly:assembly. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Error in the Caverphone implemention
Thanks Martin and Gary - sorry for my screwup.
Very happy that you found the Caverphone code however Martin :)
Hen
On Tue, Mar 1, 2011 at 9:59 AM, Gary Gregory wrote:
> The fix is in SVN and scheduled for inclusion in the upcoming Codec 1.5
> release.
>
> Thank you,
> Gary
>
> On Tue, Mar 1, 2011 at 6:05 AM, Martin Nybo Andersen wrote:
>
>> Hi,
>>
>> On Mon, 28 Feb 2011, Matt Benson wrote:
>>
>> Finally, given the fact that we are discussing patches (which have to
>>> be granted IP blah blah blah anyway) as well as the fact that you are
>>> not subscribed to the developer list, this exchange should be
>>> conducted in JIRA.
>>>
>>> Matt
>>>
>>
>> I wrote the mail to raise a flag. You saw it, which was my intention. I'm
>> happy now.
>>
>> To create a jira account for this minor bug seems to be overkill for me.
>> Remember that the harder it is to report a bug, the fewer bugs will be
>> reported.
>>
>> I am not subscribed to this mailing list for the same reason.
>>
>> What you do with the bug now, is for you to decide.
>>
>>
>>> On Mon, Feb 28, 2011 at 10:04 AM, Gary Gregory
>>> wrote:
>>>
Would you be able to include a unit test patch in your diff file?
>>>
>> new Caverphone().encode("mbmb") currently returns "MMP111" while it
>> should return "MPM111".
>>
>>
Also, it seems that the examples from
http://en.wikipedia.org/wiki/Caverphone
do not match our code:
{"Lee", "L1"},
{"Thompson", "TMPSN1"},
>> These Caverphones seems to be version 1. Version 2 which is implemented in
>> apache.commons uses 10-letter-codes.
>>
>> Hm...
Thank you,
Gary
On Mon, Feb 28, 2011 at 8:13 AM, Martin Nybo Andersen >>> >wrote:
Hi,
>
> I've found an error in the Caverphone language codec.
>
> According to the specs at page 2 line 6:
> "If the name ends with mb make it m2".
>
> Apparently is has been interpreted as:
> "If the name _starts_ with mb make it m2".
>
> The attached patch will fix it.
>
> Please CC me, as I'm not subscribed.
>
>>
>> Regards,
>> Martin Nybo Andersen
>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Commons Lang 3.0 (RC1)
Looking to release 3.0; there's not been a lot of JIRA activity and it's 9 months or so since we released the beta. Downloads: http://people.apache.org/~bayard/commons-lang3-RC1/ Maven repo entry: http://people.apache.org/~bayard/commons-lang3-RC1/maven/ Website: http://people.apache.org/~bayard/commons-lang3-RC1/site/ Tag: https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC1 [ ] +1 [ ] -1, because: Thanks, Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
