Hello, I don't feel like ArithmeticException quite captures all of the possible geometry exception states. For example, it seems odd to me to throw an ArithmeticException when a plane cannot be constructed due to a given set of points being collinear [1]. That idea feels beyond the concept of "arithmetic". However, I do think that the GeometryValueException subclass is not useful and should be removed.
On a more general note, the rule I've been following recently is to throw JDK exceptions like IllegalArgumentException for programming-level errors (eg, passing an array of the wrong length to a method) and GeometryException or an appropriate subclass for errors related to geometric operations. -Matt [1] https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/Plane.java#L733 ________________________________ From: Gilles Sadowski <gillese...@gmail.com> Sent: Thursday, November 28, 2019 8:54 PM To: Commons Developers List <dev@commons.apache.org> Subject: [Geometry] Exceptions hierarchy Hello. Is there any value added by "GeometryException" over the standard "ArithmeticException"? If not, I'd rather have the public API advertize the latter. We could have an *internal* utility class that instantiates exceptions: ---CUT--- public class ExceptionFactory { public ArithmeticException illegalNorm(double norm) { return new ArithmeticException("Illegal norm: " + norm); } } ---CUT--- Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
