[
https://issues.apache.org/jira/browse/LUCENE-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249733#comment-13249733
]
Uwe Schindler commented on LUCENE-3969:
---------------------------------------
Hi Robert, no generics complaints, it cannot be done better (means
warning-free, that's a backwards-API-bug in Java - as always. Reflection-APIs
and other APIs in general should return collections not raw arrays; the
horrible thing here is that reflection have to create a new array on every
invocation (clone), as it could be modified later. With Lists it could return
unmodifiableList... Oracle should fix this and break backwards, as we should
with CR.getSequentialSubReaders as there is not overhead at all).
I am a little bit irritated about the catch block:
{noformat}
+ if (e instanceof UnsupportedOperationException) {
+ // ignore
+ System.err.println("WARNING: " + e + " for " + clazz);
+ } else if (e instanceof InvocationTargetException) {
+ if (e.getCause() instanceof IllegalArgumentException ||
+ e.getCause() instanceof UnsupportedOperationException) {
+ // thats ok
+ if (VERBOSE) {
+ System.err.println("Ignoring IAE/UOE from ctor:");
+ e.printStackTrace();
+ }
+ } else {
+ // not ok
+ System.err.println(clazz);
+ throw new RuntimeException(e);
+ }
+ } else {
+ throw new RuntimeException(e);
+ }
{noformat}
The first check for Unsupported cannot come from the called ctor only from
reflection code itsself, but reflection should not throw UOE.
When you call a ctor with reflection, every Throwable the CTOR throws is
wrapped by InvocationTargetException. So the code in my opinion should *only*
catch InvocationTargetException and then check for the corresponding "valid"
causes. All other causes (not the ITE) should be rethrown using
o.a.l.util.Rethrow (and not wrapped with Runtime). And any other
reflection-based Ex should not be catched at all.
I will play around and remove the big Exception bug.
> Use all (non-deprecated) analysis ctors in TestRandomChains
> -----------------------------------------------------------
>
> Key: LUCENE-3969
> URL: https://issues.apache.org/jira/browse/LUCENE-3969
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/analysis
> Reporter: Robert Muir
> Attachments: LUCENE-3969.patch, LUCENE-3969.patch
>
>
> We made TestRandomChains in LUCENE-3919, which reflects all
> analysis components from the classpath and builds analyzers from them,
> then checks consistency.
> but currently it only supports some tokenizers/tokenfilters/charfilters,
> because it hardcodes at certain ctors e.g. Tokenizer(Reader) and
> Tokenizer(Version+Reader).
> Instead we should use all ctors, just filling them in with random data of
> whatever argument type they take.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
