[geometry] Exceptions (Was: Initial Project Structure)

[Gilles]

On Mon, 16 Apr 2018 01:38:39 +0000, Matt Juntunen wrote:

[...]


Gilles:
only JDK exception types are part of the public API
I see what you're talking about with the exceptions in
commons-numbers but I don't understand the reasoning behind it.

It's a long story; there are literally hundreds of posts
about this, dating back more than 10 years!

Why don't we want to expose custom exception types to users?
Wouldn't they
want to be able to write catch clauses for specific conditions?

The question "Why would they want to catch specific condition?"
must be asked, for each condition.
It turned out that, in the vast majority of cases, the exception
indicates a programming error or an implementation weakness.
Hence, there is no runtime fix ("retry") and catching specific
exceptions has no more value than catching all of them (the
likely goal being to avoid that the JVM terminates).

In the
case of the geometry code, one big condition that comes up all the

time is the zero norm condition. This is why I have a special type for

it.

A custom exception class is certainly useful from the
developer's POV (code reuse).  A problem (prior to Java 9)
is that it must be public in order to be accessible from
another package.  [Hence, in "Numbers", the purpose of
package-private exceptions per package.]
If the same exception is needed through module boundaries,
we could define it in an "internal" package:
  o.a.c.geometry.internal.exception
to clearly mean that it is not for user's consumption.
[This convention is accepted in "Commons" to mean that
no promise is made for code that resides in such a
package.]
Now that I think of it, we could even create a
  commons-geometry-internal
module to contain private and/or beta codes.  This would
prepare for the future (when usage of a "module-info" file
will allow to enforce access restriction).

Regards,
Gilles

[...]

Thanks,
Matt

[...]

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