I suppose I could get on board with removing the GeometryException base class
and only using JDK exceptions in the public API. I think the best exceptions in
that case would be IllegalArgumentException and IllegalStateException,
depending on the specific case.
-Matt
________________________________
From: Gilles Sadowski <gillese...@gmail.com>
Sent: Tuesday, December 3, 2019 11:42 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [Geometry] Exceptions hierarchy
Hello.
2019-12-03 17:13 UTC+01:00, Matt Juntunen <matt.juntu...@hotmail.com>:
> 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].
In that method, argument "pts" (the list of points) is for all
purpose, a caller's mistake (requesting a plane from collinear
points), hence the result of the call should actually be that a
"IllegalArgumentException" is thrown.
I'd suggest that the "fromPoints" be refactored into
---CUT---
public static boolean isCollinear(Collection<Vector3D> pts,
DoublePrecisionContext prec)
---CUT---
and
---CUT---
public static Plane fromPoints(Collection<Vector3D> pts,
DoublePrecisionContext prec) {
// ...
if (isCollinear(pts, prec)) {
throw new IllegalArgumentException("Collinear points");
}
// ...
}
---CUT---
> That idea feels beyond the concept of
> "arithmetic".
IMHO, we should aim for the leanest API. In the above case, nothing
is added by throwing a custom type.
> However, I do think that the GeometryValueException subclass
> is not useful and should be removed.
+1
> 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.
I understand the willingness to make a distinction but what purpose
does it serve from a user's POV? And from our POV, all these "little"
things will get in the way of making changes that are backwards BC.
Gilles
>
> -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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
