commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tharaka De Silva <tharaka...@gmail.com>
Subject Re: NUMBERS-40: Review exception usage in package "o.a.c.numbers.gamma"
Date Fri, 09 Jun 2017 00:38:55 GMT
Thank you for the response!

On Thu, Jun 8, 2017 at 5:13 AM, Gilles <gilles@harfang.homelinux.org> wrote:

> Hi.
>
> On Wed, 7 Jun 2017 17:00:46 -0500, Tharaka De Silva wrote:
>
>> Hello everyone,
>>
>> I am new to the ASF community
>>
>
> Welcome.


Thank you!


>
>
> and decided to grab something easy to
>> attempt. I decided to take a shot at:
>> https://issues.apache.org/jira/browse/NUMBERS-40.
>>
>
> Easy to change is not always similar to easy to decide what
> changes to perform. ;-)
>
>
I did not think of it that way. It makes sense.


>
>> The rationale of implementing this design would be this:
>> GammaException is currently a subclass of IllegalArgumentException but the
>> reason for an argument to be invalid would be because it is arithmetically
>> impossible hence why it should be an ArithmeticException rather than a
>> IllegalArgumentException.
>>
>
> In quite a few cases, it is actually _not_ "arithmetically impossible",
> it is a limitation of the implementation.
>

I was looking at it and the one I saw was for negative log and I made my
assumptions from that.


>
> The JIRA report asks whether it is possible to use a single exception
> type (currently "GammaException") for all programming errors, given that
> the base class of all errors _cannot_ be "ArithmeticException" (as the
> above explains).
>
>
So you think that leaving it as a subclass of IllegalArgumentException
makes more sense?


> As an aside, in the unit tests, the use of the exception's base (JDK)
> class in the "expected" clause is intentional as the unit tests are
> mainly supposed to  check the public API (and "GammaException" is
> package-private).
> In "Commons Numbers", the idea would be to have a most simple exception
> handling (throwing only JDK exceptions) since it is expected (TBC) that
> all of them result from incorrect usage or bugs in the library.
>

Yeah, I didn't think of it this way. The unit tests probably should
probably be modified to assert for the JDK exceptions.


>
>
> Regards,
> Gilles
>
>
>> What do you guys think?
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Sincerely,

Tharaka De Silva

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message