commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Restoring IAE to MathUtils#binomialCoefficient methods
Date Sun, 01 May 2011 13:40:49 GMT
Le 01/05/2011 15:00, Gilles Sadowski a écrit :
> On Sun, May 01, 2011 at 12:48:14PM +0200, Gilles Sadowski wrote:
>> On Sat, Apr 30, 2011 at 10:53:30PM -0700, Phil Steitz wrote:
>>> On 4/30/11 4:33 PM, Gilles Sadowski wrote:
>>>> On Sat, Apr 30, 2011 at 09:10:08AM -0700, Phil Steitz wrote:
>>>>> Converting some of my code to use trunk, I discovered that the
>>>>> binomialCoefficient methods no longer throw IllegalArgumentException
>>>>> when parameters are invalid.
>>>> The consensus was a singly rooted hierarchy ("MathRuntimeException").
>>>> The advantage being commonly agreed on was to offer the "map" functionality
>>>> for adding messages and context information.
>>> I guess I misunderstood and after really seeing the consequences in
>>> my own code, I am going to have to ask that we reopen that
>>> discussion - i.e., I would like us to throw IAE and other standard
>>> exceptions where appropriate, as in this case, as we have up to and
>>> through 2.2.  I know I said before that I did not see this as worth
>>> arguing about, but I really think this change is a bad API design
>>> decision that will cause needless hassle and surprising RTEs for
>>> users upgrading to the new version.
>> I'm astonished, and for the time being, will refrain from other comments.
> There is no one single best API design. What counts most IMO is that it is
> consistent and leads to clean and lean code.
> The old exception factories à la
> -----
>    MathRuntimeException.createIllegalArgumentException("Error with an argument {0}",
> -----
> failed on all accounts.
> Now, I would like to settle this issue once for all.


> Should all CM
> exceptions inherit from the standard Java exceptions hierarchies (rooted at
> IAE, UOE, NPE, AE, etc.)?  Although it had been answered "no" previously, it
> was not my preferred choice.

Choose as you want. I won't voice any opinion here.

> I could make it "yes" now but I'd rather not
> changed that back and forth again and again.



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

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

View raw message