sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (SIS-348) CompoundFormat.parse(CharSequence text, ParsePosition pos) javadoc is inconsistent with implementation
Date Fri, 17 Nov 2017 14:12:00 GMT

     [ https://issues.apache.org/jira/browse/SIS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martin Desruisseaux closed SIS-348.
-----------------------------------

> CompoundFormat.parse(CharSequence text, ParsePosition pos) javadoc is inconsistent with
implementation
> ------------------------------------------------------------------------------------------------------
>
>                 Key: SIS-348
>                 URL: https://issues.apache.org/jira/browse/SIS-348
>             Project: Spatial Information Systems
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>            Reporter: Martin Desruisseaux
>            Assignee: Martin Desruisseaux
>             Fix For: 0.8
>
>
> In the {{CompoundFormat}} class, the Javadoc of following method give a description of
{{ParseException.getErrorOffset()}} value which is inconsistent with what most Apache SIS
implementations actually do:
> {code:java}
> public abstract T parse(CharSequence text, ParsePosition pos) throws ParseException;
> {code}
> The current specification of above method is more convolved than what we usually expect
from a method throwing {{ParseException}}. It said that the error offset of the exception
is relative to the error index of the {{ParsePosition}}. But the {{TreeTableFormat}} subclass
is the only one to follow that specification; all other subclasses apply the more usual and
straightforward interpretation where {{ParseException.getErrorOffset()}} gives directly the
index where parsing error occurred.
> Instead than modifying {{WKTFormat}} - which is a much more sensitive subclass than {{TreeTableFormat}},
we should rather modify the {{CompoundFormat.parse(CharSequence, ParsePosition)}} specification
for making it less surprising and adapt {{TreeTableFormat}} accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message