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 thetime is the zero norm condition. This is why I have a special type forit.
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: [email protected] For additional commands, e-mail: [email protected]
