[
https://issues.apache.org/jira/browse/LUCENE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142316#comment-14142316
]
Ryan Ernst commented on LUCENE-5952:
------------------------------------
bq. I agree we should put these methods in CodecUtil (CodecUtil.readVersion,
writeVersion)
IMO they should be part of the Version class, so that the constructor can stay
private. No one should be constructing Versions, they should be using the
constants, or parsing/reading them.
> Give Version parsing exceptions more descriptive error messages
> ---------------------------------------------------------------
>
> Key: LUCENE-5952
> URL: https://issues.apache.org/jira/browse/LUCENE-5952
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.10
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Blocker
> Fix For: 4.10.1, 5.0, Trunk
>
> Attachments: LUCENE-5952.patch, LUCENE-5952.patch, LUCENE-5952.patch,
> LUCENE-5952.patch, LUCENE-5952.patch, LUCENE-5952.patch
>
>
> As discussed on the dev list, it's spooky how Version.java tries to fully
> parse the incoming version string ... and then throw exceptions that lack
> details about what invalid value it received, which file contained the
> invalid value, etc.
> It also seems too low level to be checking versions (e.g. is not future proof
> for when 4.10 is passed a 5.x index by accident), and seems redundant with
> the codec headers we already have for checking versions?
> Should we just go back to lenient parsing?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
