You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Barnhill <er...@gmail.com> on 2016/12/13 13:57:04 UTC
Re: [complex][math-util] dependencies
On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gi...@harfang.homelinux.org>
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
Re: [complex][math-util] dependencies
Posted by Gary Gregory <ga...@gmail.com>.
On Dec 15, 2016 6:03 AM, "Jörg Schaible" <jo...@bpm-inspire.com>
wrote:
Hi Gary,
Gary Gregory wrote:
> On Tue, Dec 13, 2016 at 9:59 AM, Gilles <gi...@harfang.homelinux.org>
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [complex][math-util] dependencies
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Hi Gary,
Gary Gregory wrote:
> On Tue, Dec 13, 2016 at 9:59 AM, Gilles <gi...@harfang.homelinux.org>
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [complex][math-util] dependencies
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 13, 2016 at 9:59 AM, Gilles <gi...@harfang.homelinux.org>
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" <er...@gmail.com> wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gi...@harfang.homelinux.org>
>>> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [complex][math-util] dependencies
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 13, 2016 at 9:59 AM, Gilles <gi...@harfang.homelinux.org>
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" <er...@gmail.com> wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gi...@harfang.homelinux.org>
>>> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [complex][math-util] dependencies
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <er...@gmail.com>
> wrote:
>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles
>> <gi...@harfang.homelinux.org>
>> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [complex][math-util] dependencies
Posted by Gary Gregory <ga...@gmail.com>.
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" <er...@gmail.com> wrote:
> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gi...@harfang.homelinux.org>
> 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
>