commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Tue, 04 Sep 2012 05:49:23 GMT

I realize I'm a little late to the party here, so if I'm asking or suggesting things that
are naive just let me know straight up, and I'll try to educate myself better.  I will say
that I really enjoy reading these threads because I learn a great deal from them.

As a user of commons math I think it would be great if a each exception mapped to a "One of
a kind problem".  So instead of having a NegativeIntegerException, which is generic and could
be used in a lot of places, have SuperDuperOptimizerNegativeIntegerException, which is only
thrown in one place.

Is this possible?

- Ole

On 09/03/2012 03:56 PM, Gilles Sadowski wrote:
>>> [...]
>>> There must be something imprecise in the CM project description which I've
>>> read somewhere, mentioning "state-of-the-art". I understood it as "best
>>> practices in Java programming and OO design", but I must have been wrong.
>> Probably what you remember reading is this on the home page:
>> " All algorithms are fully documented and follow generally accepted
>> best practices."
> Yes, that's it.
> And indeed, the first thing that came to my mind is "best [programming]
> practices".
> Those best practices evolve over time and vary with the language (or more
> exactly, with the paradigm supported by the language).
> [For an example of both and how incoherent, incomprehensible and
> unmaintainable a code can be when we mix oil and water, please look at
> "BOBYQAOptimizer"! And this is already after dozens of hours converting from
> Fortran (goto etc.) to Java (OO).]
>> We have never claimed to be anything more than a practially useful,
>> open source, open-development Java mathematics library implementing
>> standard algorithms with no dependencies or IP encumberance and good
>> documentation.  This is consistent with how other Commons components
>> describe themselves.  The key is that *usefulness*, *ease of use*
>> and *approachability of the code* is more important than any one
>> developer's idea of what constitutes "best coding practices" or
>> "state-of-the-art" Java (whatever that means).
> None of the qualities which you cite as worthy goals are in contradiction
> with what you say is less important.
> In fact, quite the contrary, applying the paradigm supported by the language
> improves everything else (ease of use, approachability, hence usefulness).
> In our case, respecting the basic tenets of object-oriented programming
> should be a top (!) priority if we hope to to build a library for the
> longer term.
> IMHO, we should promote Java (OO) state-of-the-art best practices when
> designing the API and writing the code.
> Sometimes, we can arrive to a dead-end, where we'd need to derogate to the
> rules. At that point we might realize that the design was not good enough
> to cater for all (new) the requirements.
> If we have to maintain compatibility, and if there is really no other
> choice, only then should we be allowed to break the rules.
> If we can break compatibility, then the design can be evolved, based on the
> new insights. Failing to do that from time to time will be the cause of the
> demise of CM (as of many other programming projects).
>> It seems a reasonable compromise in this case would be to provide
>> the getters that Luc is asking for (making the library easier to
>> use), while at the same time continuing to build out the exception
>> hierarchy so that more use cases can be handled without
>> programmatically unpacking exception contexts.
> All I suggest is that we are aware that there is something fundamentally
> wrong (in the sense of OO fundamentals) with the approach which you aptly
> describe as "unpacking exception contexts".
> [I think that this and other decisions will hurt the project later. But
> I can understand that a pressing need might need to be solved urgently.
> I did not mean to oppose adding the accessors (I even thought they existed
> already!); I am arguing about the principles.]
> We should also acknowledge that this change is useful only for people who
> will actually _read the source code_ (in order to spot what pattern was
> passed to the raised exception): the pattern is not documented (and rightly
> so IMO!).
> Until we have cleaned up the "LocalizedFormats" (removing all duplicates or
> near duplicates), we should not be tied to keep any pattern in the API.
> Regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message