On Tue, Dec 13, 2016 at 9:59 AM, Gilles <gil...@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" <ericbarnh...@gmail.com> wrote:
>>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gil...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@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
