Hello.

Le mar. 7 juil. 2020 à 03:41, Matt Juntunen
<matt.juntu...@hotmail.com> a écrit :
>
> Hi Gilles,
>
> I made the change because it seemed logical (to me) and sufficiently trivial 
> (internal class with 2 usages). I don't really care too much either way so 
> I'll go ahead and revert it. Commons Math has MathInternalError so there is 
> precedent for this naming convention.
>
> In regard to it not being part of the public API, this is indicated by its 
> presence in the "o.a.c.geometry.core.internal" package.

Yes; we discussed that convention.
Using a method could perhaps avoid even declaring
a class. [It could reduce the number of errors in future
compatibility checks.]

Regards,
Gilles

>
> -Matt
>
>
>
>
>
> ________________________________
> From: Gilles Sadowski <gillese...@gmail.com>
> Sent: Sunday, July 5, 2020 2:12 PM
> To: Commons Developers List <dev@commons.apache.org>
> Subject: Re: [commons-geometry] 11/11: change GeometryInternalError to 
> GeometryInternalException to better reflect its actual type
>
> Hi.
>
> Le dim. 5 juil. 2020 à 13:26, Matt Juntunen
> <matt.juntu...@hotmail.com> a écrit :
> >
> > What are your objections to the name? The new name is more consistent with 
> > JDK conventions.
>
> It is a programming error (as opposed to a usage error, which
> subclasses of "RuntimeException" represent).  As such it is
> more self-documenting (IMHO) to keep the previous name.
> JDK's use of the English word "Error" should not prevent all
> application to use it.  There is no implied relationship to the
> JDK's "Error" hierarchy.
>
> >
> > Also, this class is not part of the public API.
>
> An alternative to make it that clear is perhaps to have an
> "InternalUtils" class (untested):
>
> public class InternalUtils {
>     private static String INTERNAL_ERROR_MESSAGE = "...";
>
>     public static void throwInternalError() {
>         throw new GeometryInternalError();
>     }
>
>     private static class GeometryInternalError extends IllegalStateException {
>         // ...
>     }
> }
>
> Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to