[Geometry] Exceptions hierarchy

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Geometry] Exceptions hierarchy

Gilles Sadowski-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Geometry] Exceptions hierarchy

Matt Juntunen
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 <[hidden email]>
Sent: Thursday, November 28, 2019 8:54 PM
To: Commons Developers List <[hidden email]>
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Geometry] Exceptions hierarchy

Gilles Sadowski-2
Hello.

2019-12-03 17:13 UTC+01:00, Matt Juntunen <[hidden email]>:
> 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 <[hidden email]>
> Sent: Thursday, November 28, 2019 8:54 PM
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Geometry] Exceptions hierarchy

Matt Juntunen
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 <[hidden email]>
Sent: Tuesday, December 3, 2019 11:42 AM
To: Commons Developers List <[hidden email]>
Subject: Re: [Geometry] Exceptions hierarchy

Hello.

2019-12-03 17:13 UTC+01:00, Matt Juntunen <[hidden email]>:
> 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 <[hidden email]>
> Sent: Thursday, November 28, 2019 8:54 PM
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]