[complex][math-util] dependencies

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[complex][math-util] dependencies

Eric Barnhill
I thought it would be good to raise a structural question here rather than
in the commons-complex JIRA.

The Complex library has multiple dependencies on three packages:

-- commons-math base classes (e.g. Field et al.)
-- commons-math exceptions
-- commons-math util (numerous classes)

Otherwise it is self-contained. (Some tests within the  QuaternionTest
class use a large chain of dependencies from the geometry package, so I
think it is best to simply remove the geometry-dependent tests until
someone arrives to maintain that library.)

This suggests to me that, if we were to continue with some kind of
math-utils base class, it should consist of these three current packages:
the base classes, util and exception. It might in fact make sense to spin
out this base library first (which I am happy to oversee) then return to
finishing out the independent complex library with only commons-math-util
as dependency. Would this also be compatible with the current trajectory of
RNG?

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Jörg Schaible
Hi Eric,

Eric Barnhill wrote:

> I thought it would be good to raise a structural question here rather than
> in the commons-complex JIRA.
>
> The Complex library has multiple dependencies on three packages:
>
> -- commons-math base classes (e.g. Field et al.)
> -- commons-math exceptions
> -- commons-math util (numerous classes)
>
> Otherwise it is self-contained. (Some tests within the  QuaternionTest
> class use a large chain of dependencies from the geometry package, so I
> think it is best to simply remove the geometry-dependent tests until
> someone arrives to maintain that library.)
>
> This suggests to me that, if we were to continue with some kind of
> math-utils base class, it should consist of these three current packages:
> the base classes, util and exception. It might in fact make sense to spin
> out this base library first (which I am happy to oversee) then return to
> finishing out the independent complex library with only commons-math-util
> as dependency.

It seems you try to create what commons-math should have been ;-)

However, I'd avoid the term "utils" in a components name, it sounds
immediately again as dumping ground for all kind of stuff. What about
commons-math-base?

> Would this also be compatible with the current trajectory
> of RNG?

It's IMHO independent. It boils down more to the point if we agree that
there will be never a release of commons-math4.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Gilles Sadowski
In reply to this post by Eric Barnhill
Hello Eric.

On Tue, 29 Nov 2016 14:19:54 +0100, Eric Barnhill wrote:
> I thought it would be good to raise a structural question here rather
> than
> in the commons-complex JIRA.
>
> The Complex library has multiple dependencies on three packages:
>
> -- commons-math base classes (e.g. Field et al.)

Do you foresee any application for "Field" or "FieldElement" classes
in this component?
If not, just drop them.

> -- commons-math exceptions

In "Commons RNG", I completely dropped all custom-made exceptions.
I suggest you do the same here.
IMO, "simple", low-level, components can do with just throwing
runtime exceptions from the standard library (with a hard-coded
_English_ message).

> -- commons-math util (numerous classes)

My suggestions:

  * CompositeFormat: drop
  * FastMath: replace with JDK's "Math" calls[1]
  * IntegerSequence: use a _private_ copy[2][3]
  * MathUtils:
    - drop "checkNotNull"[4]
    - drop "equals(double,double)", "hash(double)" and
      "hash(double[])"[5]
  * Precision: extract the needed bits and make a private copy.

[1] Until we set out to make them interchangeable at runtime.
[2] Until we agree on creating a component for _very_ low-level
     utilities, and on its contents.
[3] Like I did with classes "InternalUtils" and "InternalGamma"
     in the "sampling" module of "Commons RNG".
[4] Let the JVM do it.
[5] They are trivial; use methods from the JDK directly.

>
> Otherwise it is self-contained. (Some tests within the  
> QuaternionTest
> class use a large chain of dependencies from the geometry package, so
> I
> think it is best to simply remove the geometry-dependent tests until
> someone arrives to maintain that library.)

Better keep the tests, and make "Commons Math" (v3.6.1) a
dependency with scope "test" (as I did for module "sampling"
in "Commons RNG").

>
> This suggests to me that, if we were to continue with some kind of
> math-utils base class, it should consist of these three current
> packages:
> the base classes, util and exception.

Probably best to start from requirements, rather than previous design.
As per the above, this discussion can be postponed.

> It might in fact make sense to spin
> out this base library first (which I am happy to oversee) then return
> to
> finishing out the independent complex library with only
> commons-math-util
> as dependency.

That's not going to work here. [Been there, done that.]
Better create something directly useful (to you and others) and
as a building block for "SigProc".
Once there are "clients", it will be time to refactor a "base"
component from the "private" parts of "Commons Complex".

> Would this also be compatible with the current trajectory of
> RNG?

I don't understand the question.

Best,
Gilles

>
> Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
In reply to this post by Eric Barnhill
On Tue, Nov 29, 2016 at 5:19 AM, Eric Barnhill <[hidden email]>
wrote:

> I thought it would be good to raise a structural question here rather than
> in the commons-complex JIRA.
>
> The Complex library has multiple dependencies on three packages:
>
> -- commons-math base classes (e.g. Field et al.)
> -- commons-math exceptions
> -- commons-math util (numerous classes)
>
> Otherwise it is self-contained. (Some tests within the  QuaternionTest
> class use a large chain of dependencies from the geometry package, so I
> think it is best to simply remove the geometry-dependent tests until
> someone arrives to maintain that library.)
>
> This suggests to me that, if we were to continue with some kind of
> math-utils base class,


Don't you mean a... what? package? Maven module?

Gary


> it should consist of these three current packages:
> the base classes, util and exception. It might in fact make sense to spin
> out this base library first (which I am happy to oversee) then return to
> finishing out the independent complex library with only commons-math-util
> as dependency. Would this also be compatible with the current trajectory of
> RNG?
>
> Eric
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
In reply to this post by Jörg Schaible
On Tue, Nov 29, 2016 at 11:39 AM, Jörg Schaible <[hidden email]>
wrote:

> Hi Eric,
>
> Eric Barnhill wrote:
>
> > I thought it would be good to raise a structural question here rather
> than
> > in the commons-complex JIRA.
> >
> > The Complex library has multiple dependencies on three packages:
> >
> > -- commons-math base classes (e.g. Field et al.)
> > -- commons-math exceptions

> -- commons-math util (numerous classes)
>

Are these Java packages (packages cannot have - in the name) or Maven
modules?


> >
> > Otherwise it is self-contained. (Some tests within the  QuaternionTest
> > class use a large chain of dependencies from the geometry package, so I
> > think it is best to simply remove the geometry-dependent tests until
> > someone arrives to maintain that library.)
> >
> > This suggests to me that, if we were to continue with some kind of
> > math-utils base class, it should consist of these three current packages:
> > the base classes, util and exception. It might in fact make sense to spin
> > out this base library first (which I am happy to oversee) then return to
> > finishing out the independent complex library with only commons-math-util
> > as dependency.
>
> It seems you try to create what commons-math should have been ;-)
>
> However, I'd avoid the term "utils" in a components name, it sounds
> immediately again as dumping ground for all kind of stuff.


+1, "utils" is never a good name. It feels like I could not think of a good
name. Also, it encourages the class/package/module to become a disorganized
kitchen sink of piled up dishes ;-)


> What about
> commons-math-base?
>
> > Would this also be compatible with the current trajectory
> > of RNG?
>
> It's IMHO independent. It boils down more to the point if we agree that
> there will be never a release of commons-math4.
>

It's not clear to me what we are really talking about here in the big
picture.

I really do not think it is a good idea to end up with a bunch of math
components in Commons. We have Commons Math, that component can have
different modules if it wants to slice and dice itself.

We could "shelve" math4 and have a math5 with all of the modules being
discussed here and there.

Gary


>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Gilles Sadowski
On Tue, 29 Nov 2016 12:26:53 -0800, Gary Gregory wrote:

> On Tue, Nov 29, 2016 at 11:39 AM, Jörg Schaible
> <[hidden email]>
> wrote:
>
>> Hi Eric,
>>
>> Eric Barnhill wrote:
>>
>> > I thought it would be good to raise a structural question here
>> rather
>> than
>> > in the commons-complex JIRA.
>> >
>> > The Complex library has multiple dependencies on three packages:
>> >
>> > -- commons-math base classes (e.g. Field et al.)
>> > -- commons-math exceptions
>
>> -- commons-math util (numerous classes)
>>
>
> Are these Java packages (packages cannot have - in the name) or Maven
> modules?

Eric referred to "Commons Math" layout:
  base -> (top-level) package o.a.c.m
  exception -> package o.a.c.m.exception
  util -> package o.a.c.m.util


>> >
>> > Otherwise it is self-contained. (Some tests within the  
>> QuaternionTest
>> > class use a large chain of dependencies from the geometry package,
>> so I
>> > think it is best to simply remove the geometry-dependent tests
>> until
>> > someone arrives to maintain that library.)
>> >
>> > This suggests to me that, if we were to continue with some kind of
>> > math-utils base class, it should consist of these three current
>> packages:
>> > the base classes, util and exception. It might in fact make sense
>> to spin
>> > out this base library first (which I am happy to oversee) then
>> return to
>> > finishing out the independent complex library with only
>> commons-math-util
>> > as dependency.
>>
>> It seems you try to create what commons-math should have been ;-)
>>
>> However, I'd avoid the term "utils" in a components name, it sounds
>> immediately again as dumping ground for all kind of stuff.
>
>
> +1, "utils" is never a good name. It feels like I could not think of
> a good
> name. Also, it encourages the class/package/module to become a
> disorganized
> kitchen sink of piled up dishes ;-)

What about discussing actual contents (scope) rather than names?

>> What about
>> commons-math-base?
>>
>> > Would this also be compatible with the current trajectory
>> > of RNG?
>>
>> It's IMHO independent. It boils down more to the point if we agree
>> that
>> there will be never a release of commons-math4.
>>
>
> It's not clear to me what we are really talking about here in the big
> picture.

There we can agree.

>
> I really do not think it is a good idea to end up with a bunch of
> math
> components in Commons. We have Commons Math, that component can have
> different modules if it wants to slice and dice itself.

Oh, no, that ain't so.
Please look at the archives.

> We could "shelve" math4 and have a math5 with all of the modules
> being
> discussed here and there.

What's about "5"?
I'd prefer "14", for no particular reason. :-)

Gilles

>
> Gary
>
>
>>
>> Cheers,
>> Jörg
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
In reply to this post by Eric Barnhill
On Tue, Nov 29, 2016 at 5:19 AM, Eric Barnhill <[hidden email]>
wrote:

> I thought it would be good to raise a structural question here rather than
> in the commons-complex JIRA.
>
> The Complex library has multiple dependencies on three packages:
>
> -- commons-math base classes (e.g. Field et al.)

-- commons-math exceptions
>

I have never been a fan of packages that include all exceptions. It does
not make sense to me. If an exception is only used in package foo, it
should be defined in that package.

If it is used in foo.one and foo.bar, maybe it belongs in foo. YMMV. But
kitchen-sink package for all exceptions does not seem like good design to
me.

2c,
Gary


> -- commons-math util (numerous classes)
>
> Otherwise it is self-contained. (Some tests within the  QuaternionTest
> class use a large chain of dependencies from the geometry package, so I
> think it is best to simply remove the geometry-dependent tests until
> someone arrives to maintain that library.)
>
> This suggests to me that, if we were to continue with some kind of
> math-utils base class, it should consist of these three current packages:
> the base classes, util and exception. It might in fact make sense to spin
> out this base library first (which I am happy to oversee) then return to
> finishing out the independent complex library with only commons-math-util
> as dependency. Would this also be compatible with the current trajectory of
> RNG?
>
> Eric
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Eric Barnhill
In reply to this post by Gilles Sadowski
On Tue, Nov 29, 2016 at 8:48 PM, Gilles <[hidden email]>
wrote:

> Hello Eric.
>
> On Tue, 29 Nov 2016 14:19:54 +0100, Eric Barnhill wrote:
>
>> I thought it would be good to raise a structural question here rather than
>> in the commons-complex JIRA.
>>
>> The Complex library has multiple dependencies on three packages:
>>
>> -- commons-math base classes (e.g. Field et al.)
>>
>
> Do you foresee any application for "Field" or "FieldElement" classes
> in this component?
> If not, just drop them.
>

There is a ComplexField class. To keep my thoughts short, it looks like the
highly generic Field hierarchy does not have a place in C-M anymore and
should be dropped, including ComplexField.


>
> -- commons-math exceptions
>>
>
> In "Commons RNG", I completely dropped all custom-made exceptions.
> I suggest you do the same here.
> IMO, "simple", low-level, components can do with just throwing
> runtime exceptions from the standard library (with a hard-coded
> _English_ message).
>

Almost all of these are called in the various dependent classes. Given your
suggestions for getting rid of the dependent classes this should become
simple to fix.



>
> -- commons-math util (numerous classes)
>>
>
> My suggestions:
>
>  * CompositeFormat: drop
>  * FastMath: replace with JDK's "Math" calls[1]
>  * IntegerSequence: use a _private_ copy[2][3]
>  * MathUtils:
>    - drop "checkNotNull"[4]
>    - drop "equals(double,double)", "hash(double)" and
>      "hash(double[])"[5]
>  * Precision: extract the needed bits and make a private copy.
>
> [1] Until we set out to make them interchangeable at runtime.
> [2] Until we agree on creating a component for _very_ low-level
>     utilities, and on its contents.
> [3] Like I did with classes "InternalUtils" and "InternalGamma"
>     in the "sampling" module of "Commons RNG".
> [4] Let the JVM do it.
> [5] They are trivial; use methods from the JDK directly.
>
>
>> Otherwise it is self-contained. (Some tests within the  QuaternionTest
>> class use a large chain of dependencies from the geometry package, so I
>> think it is best to simply remove the geometry-dependent tests until
>> someone arrives to maintain that library.)
>>
>
> Better keep the tests, and make "Commons Math" (v3.6.1) a
> dependency with scope "test" (as I did for module "sampling"
> in "Commons RNG").
>

Okay, this all ought to work.

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Gilles Sadowski
In reply to this post by garydgregory
On Tue, 29 Nov 2016 18:44:34 -0800, Gary Gregory wrote:

> On Tue, Nov 29, 2016 at 5:19 AM, Eric Barnhill
> <[hidden email]>
> wrote:
>
>> I thought it would be good to raise a structural question here
>> rather than
>> in the commons-complex JIRA.
>>
>> The Complex library has multiple dependencies on three packages:
>>
>> -- commons-math base classes (e.g. Field et al.)
>
> -- commons-math exceptions
>>
>
> I have never been a fan of packages that include all exceptions. It
> does
> not make sense to me. If an exception is only used in package foo, it
> should be defined in that package.
>
> If it is used in foo.one and foo.bar, maybe it belongs in foo. YMMV.
> But
> kitchen-sink package for all exceptions does not seem like good
> design to
> me.

This kind of hand-waving argument serves little.
[And I'm not saying now that Commons Math's design was good or bad
in that area.]
But did you look at the subject of discussion, i.e. the package in
question and by which packages some of those exception are used?

If one considers an "error" type as a concept, then the _same_ "error"
can appear in multiple places, so this is an argument for having them
stand alone in their own package, rather than having multiple copies,
or have everything in the top-level package.[1]

But I agree that with a true "component"[2], it is probably not worth
to not having a specific "exception" package (namely because the number
of exceptions is likely to be very limited).
[I think that, on that matter, my answer to Eric was clear and in line
with your statement.]


Regards,
Gilles

[1] Which I consider bad design, for reasons not worth mentioning
     because I know (from experience, now) that this discussion
     will lead to nowhere.
[2] I.e. not with kitchen sinks that [Math] or [Lang] are now.

>
> 2c,
> Gary
>
>
>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Eric Barnhill
In reply to this post by Gilles Sadowski
On Tue, Nov 29, 2016 at 8:48 PM, Gilles <[hidden email]>
wrote:


> In "Commons RNG", I completely dropped all custom-made exceptions.
> I suggest you do the same here.
> IMO, "simple", low-level, components can do with just throwing
> runtime exceptions from the standard library (with a hard-coded
> _English_ message).


So, let's say three different methods in Quaternion throw a ZeroException
right now.

Are you happy with a coding practice of each method calling

throw new RuntimeException("Zero Exception");

or would it be preferable to write an additional method at the bottom,

private static void zeroException() {
    throw new RuntimeException("Zero Exception");
}

and call it three times?

And if I do that, I should just tally up the different exceptions in the
complex methods and have one more class, ComplexRuntimeExceptions.

Barring any further objections, this is what I'll do.

Eric
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
Two bad code smells:

Do not use RuntimeException. Is IllegalArgumentException a possibility?

Don't throw the exception in the new method, you will loose the complier's
ability to warn you about certain code paths. You can create the exception
in a new method though.

Gary

On Dec 13, 2016 5:57 AM, "Eric Barnhill" <[hidden email]> wrote:

> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <[hidden email]>
> wrote:
>
>
> > In "Commons RNG", I completely dropped all custom-made exceptions.
> > I suggest you do the same here.
> > IMO, "simple", low-level, components can do with just throwing
> > runtime exceptions from the standard library (with a hard-coded
> > _English_ message).
>
>
> So, let's say three different methods in Quaternion throw a ZeroException
> right now.
>
> Are you happy with a coding practice of each method calling
>
> throw new RuntimeException("Zero Exception");
>
> or would it be preferable to write an additional method at the bottom,
>
> private static void zeroException() {
>     throw new RuntimeException("Zero Exception");
> }
>
> and call it three times?
>
> And if I do that, I should just tally up the different exceptions in the
> complex methods and have one more class, ComplexRuntimeExceptions.
>
> Barring any further objections, this is what I'll do.
>
> Eric
>
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Gilles Sadowski
On Tue, 13 Dec 2016 08:01:35 -0800, Gary Gregory wrote:
> Two bad code smells:
>
> Do not use RuntimeException. Is IllegalArgumentException a
> possibility?

Sure, the standard exception closest to the situation should be used.

>
> Don't throw the exception in the new method, you will loose the
> complier's
> ability to warn you about certain code paths. You can create the
> exception
> in a new method though.

I don't quite follow.
Could you give a code example (do/don't)?

>
> Gary
>
> On Dec 13, 2016 5:57 AM, "Eric Barnhill" <[hidden email]>
> wrote:
>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles
>> <[hidden email]>
>> wrote:
>>
>>
>> > In "Commons RNG", I completely dropped all custom-made exceptions.
>> > I suggest you do the same here.
>> > IMO, "simple", low-level, components can do with just throwing
>> > runtime exceptions from the standard library (with a hard-coded
>> > _English_ message).
>>
>>
>> So, let's say three different methods in Quaternion throw a
>> ZeroException
>> right now.
>>
>> Are you happy with a coding practice of each method calling
>>
>> throw new RuntimeException("Zero Exception");

No.
You'll get warnings from code checkers (about string duplication).

>>
>> or would it be preferable to write an additional method at the
>> bottom,
>>
>> private static void zeroException() {
>>     throw new RuntimeException("Zero Exception");
>> }
>>
>> and call it three times?
>>
>> And if I do that, I should just tally up the different exceptions in
>> the
>> complex methods and have one more class, ComplexRuntimeExceptions.

I think that if the exact same exception is needed more than
once, it's worth creating a class.
But it will be local to the package, without parameters and
not "Localizable".

It could be package-private to benefit from encapsulation,
without extending the public API.

>>
>> Barring any further objections, this is what I'll do.

I'd refrain from defining a utility class (unless it is also
package-private, and only used as syntactic sugar).

By the way, you don't need to refer to "Runtime" in the names;
all exceptions in such codes should be unchecked.

Regards,
Gilles

>>
>> Eric
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
On Tue, Dec 13, 2016 at 9:59 AM, Gilles <[hidden email]>
wrote:

> On Tue, 13 Dec 2016 08:01:35 -0800, Gary Gregory wrote:
>
>> Two bad code smells:
>>
>> Do not use RuntimeException. Is IllegalArgumentException a possibility?
>>
>
> Sure, the standard exception closest to the situation should be used.
>
>
>> Don't throw the exception in the new method, you will loose the complier's
>> ability to warn you about certain code paths. You can create the exception
>> in a new method though.
>>
>
> I don't quite follow.
> Could you give a code example (do/don't)?
>
>
>> Gary
>>
>> On Dec 13, 2016 5:57 AM, "Eric Barnhill" <[hidden email]> wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <[hidden email]>
>>> wrote:
>>>
>>>
>>> > In "Commons RNG", I completely dropped all custom-made exceptions.
>>> > I suggest you do the same here.
>>> > IMO, "simple", low-level, components can do with just throwing
>>> > runtime exceptions from the standard library (with a hard-coded
>>> > _English_ message).
>>>
>>>
>>> So, let's say three different methods in Quaternion throw a ZeroException
>>> right now.
>>>
>>> Are you happy with a coding practice of each method calling
>>>
>>> throw new RuntimeException("Zero Exception");
>>>
>>
> No.
> You'll get warnings from code checkers (about string duplication).
>
>
>>> or would it be preferable to write an additional method at the bottom,
>>>
>>> private static void zeroException() {
>>>     throw new RuntimeException("Zero Exception");
>>> }
>>>
>>> and call it three times?
>>>
>>> And if I do that, I should just tally up the different exceptions in the
>>> complex methods and have one more class, ComplexRuntimeExceptions.
>>>
>>
> I think that if the exact same exception is needed more than
> once, it's worth creating a class.
> But it will be local to the package, without parameters and
> not "Localizable".
>
> It could be package-private to benefit from encapsulation,
> without extending the public API.
>
>
>>> Barring any further objections, this is what I'll do.
>>>
>>
> I'd refrain from defining a utility class (unless it is also
> package-private, and only used as syntactic sugar).
>
> By the way, you don't need to refer to "Runtime" in the names;
> all exceptions in such codes should be unchecked.
>

I would say "it depends". An exception should be checked if it is
recoverable. You should only used an unchecked exception if the problem
discovered is unrecoverable.

Gary

>
> Regards,
>
> Gilles
>
>
>>> Eric
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
In reply to this post by Gilles Sadowski
On Tue, Dec 13, 2016 at 9:59 AM, Gilles <[hidden email]>
wrote:

> On Tue, 13 Dec 2016 08:01:35 -0800, Gary Gregory wrote:
>
>> Two bad code smells:
>>
>> Do not use RuntimeException. Is IllegalArgumentException a possibility?
>>
>
> Sure, the standard exception closest to the situation should be used.
>
>
>> Don't throw the exception in the new method, you will loose the complier's
>> ability to warn you about certain code paths. You can create the exception
>> in a new method though.
>>
>
> I don't quite follow.
> Could you give a code example (do/don't)?


Do:

private static IllegalArgumentException createZeroException() {
    return new IllegalArgumentException("Zero Exception");
}

Don't:

private static void zeroException() {
    throw new RuntimeException("Zero Exception");
}

Gary


>
>
>
>> Gary
>>
>> On Dec 13, 2016 5:57 AM, "Eric Barnhill" <[hidden email]> wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <[hidden email]>
>>> wrote:
>>>
>>>
>>> > In "Commons RNG", I completely dropped all custom-made exceptions.
>>> > I suggest you do the same here.
>>> > IMO, "simple", low-level, components can do with just throwing
>>> > runtime exceptions from the standard library (with a hard-coded
>>> > _English_ message).
>>>
>>>
>>> So, let's say three different methods in Quaternion throw a ZeroException
>>> right now.
>>>
>>> Are you happy with a coding practice of each method calling
>>>
>>> throw new RuntimeException("Zero Exception");
>>>
>>
> No.
> You'll get warnings from code checkers (about string duplication).
>
>
>>> or would it be preferable to write an additional method at the bottom,
>>>
>>> private static void zeroException() {
>>>     throw new RuntimeException("Zero Exception");
>>> }
>>>
>>> and call it three times?
>>>
>>> And if I do that, I should just tally up the different exceptions in the
>>> complex methods and have one more class, ComplexRuntimeExceptions.
>>>
>>
> I think that if the exact same exception is needed more than
> once, it's worth creating a class.
> But it will be local to the package, without parameters and
> not "Localizable".
>
> It could be package-private to benefit from encapsulation,
> without extending the public API.
>
>
>>> Barring any further objections, this is what I'll do.
>>>
>>
> I'd refrain from defining a utility class (unless it is also
> package-private, and only used as syntactic sugar).
>
> By the way, you don't need to refer to "Runtime" in the names;
> all exceptions in such codes should be unchecked.
>
> Regards,
>
> Gilles
>
>
>>> Eric
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

Jörg Schaible-5
In reply to this post by garydgregory
Hi Gary,

Gary Gregory wrote:

> On Tue, Dec 13, 2016 at 9:59 AM, Gilles <[hidden email]>
> wrote:

[snip]

>> By the way, you don't need to refer to "Runtime" in the names;
>> all exceptions in such codes should be unchecked.
>>
>
> I would say "it depends". An exception should be checked if it is
> recoverable. You should only used an unchecked exception if the problem
> discovered is unrecoverable.

"Recoverability" also depends on the context. It can make perfectly sense
even to catch and ignore Error types.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [complex][math-util] dependencies

garydgregory
On Dec 15, 2016 6:03 AM, "Jörg Schaible" <[hidden email]>
wrote:

Hi Gary,

Gary Gregory wrote:

> On Tue, Dec 13, 2016 at 9:59 AM, Gilles <[hidden email]>
> wrote:

[snip]

>> By the way, you don't need to refer to "Runtime" in the names;
>> all exceptions in such codes should be unchecked.
>>
>
> I would say "it depends". An exception should be checked if it is
> recoverable. You should only used an unchecked exception if the problem
> discovered is unrecoverable.

"Recoverability" also depends on the context. It can make perfectly sense
even to catch and ignore Error types.


Of course, context is key, no argument there.

Gary


Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]