[
https://issues.apache.org/jira/browse/GEOMETRY-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16616513#comment-16616513
]
Gilles commented on GEOMETRY-8:
-------------------------------
{quote}see what types of situations result in GeometryExceptions by looking at
the inheritance hierarchy
{quote}
I think that this is the realm of documentation (through the "@throws" tag).
{quote}take different actions in catch clauses
{quote}
Sure but your use-case does not indicate that, and (IMO) would be covered by
looking at the message and stack trace.
The key point for is whether the code can actually do something when such an
exception would occur:
* An input error? No way we can guess what/where went wrong in upper layers
* A bug? Needs debugging and/or reporting here, not something that can be
worked around in a catch clause.
{quote}Do you have any objections to marking this issue as complete?
{quote}
I'd be more comfortable with an API minimally polluted by things that would
require the release of a new major version if they turn up to be unnecessary.
Adding to the public API later on can always be done without breaking
compatibility.
> Update Exception Instantiation
> ------------------------------
>
> Key: GEOMETRY-8
> URL: https://issues.apache.org/jira/browse/GEOMETRY-8
> Project: Apache Commons Geometry
> Issue Type: Task
> Reporter: Matt Juntunen
> Priority: Major
>
> Update exception instantiation following the pattern in commons-numbers, eg.
> custom private exception types created through factories. See the discussion
> on GEOMETRY-2 and the GammaException class and its use in LogBeta in
> commons-numbers.
>
> Based on discussion in GEOMETRY-9, we are going to implement our own
> exception hierarchy for this component, eg GeometryException and subclasses.
>
> Pull request: [https://github.com/apache/commons-geometry/pull/9]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
