[
https://issues.apache.org/jira/browse/GEOMETRY-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386928#comment-17386928
]
Gilles Sadowski commented on GEOMETRY-138:
------------------------------------------
IMO, specific exceptions are not needed in the public API (and they are not
desirable from a maintenance POV).
In principle, when the error is caused by a mismatch between expectation and
user-provided input, an {{IllegalArgumentException}} is appropriate for
carrying the message about the failure (being non-recoverable in any way other
than passing input that is compliant).
Note that I once was a proponent of providing error semantics through exception
types (hence the exception zoo in "Commons Math"). But this was based on the
belief that an application might want to programmatically retrieve detailed
information about the failure (say, the lower and upper bounds in case of an
"out-of-range" exception) for the purpose of e.g. displaying it in some
specific way.
Eventually I realized that this feature was never used (probably because
careful applications intercept faulty input _before_ calling a method that is
properly documented to throw on failure, where it knows the arguments).
["Careless" applications don't need this either because they hope for the best
and just let the exception propagate.]
{quote}why would we create a library-specific exception type for the IO modules
{quote}
As per the above, we don't actually need (IMHO) to report an IO exception as
such; the message can provide all the information (after all, what's important
is the file name, not the type of exception raised).
[UncheckedIOException|https://docs.oracle.com/javase/8/docs/api/java/io/UncheckedIOException.html]
can be used to satisfy your wish of singling out a failure that comes from a
file. However, I still think that the examples in the [ML
post|https://markmail.org/message/bvtwv7kmkie5zccc] should preferably point to
illegal input rather than an IO issue, but I admit that this is a matter of
taste (as long as we avoid the checked exception plague).
{quote}handle cases such as illegal norms and such
{quote}
IMO, they should be handled the same, with a standard (runtime) exception, as
currently done.
{quote}I recall us wanting to stick with JDK exceptions in the general case.
{quote}
Yes.
> Use unchecked exceptions in IO modules
> --------------------------------------
>
> Key: GEOMETRY-138
> URL: https://issues.apache.org/jira/browse/GEOMETRY-138
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Priority: Major
>
> The IO modules should not throw checked exceptions, e.g. {{IOException}}.
> Instead, a new unchecked {{GeometryIOException}} class should be created to
> represent all IO and parsing failures.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
