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" <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
