commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [complex][math-util] dependencies
Date Tue, 13 Dec 2016 17:59:01 GMT
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" <ericbarnhill@gmail.com> 
> wrote:
>
>> On Tue, Nov 29, 2016 at 8:48 PM, Gilles 
>> <gilles@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


Mime
View raw message