[
https://issues.apache.org/jira/browse/LUCENE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153569#comment-16153569
]
Uwe Schindler edited comment on LUCENE-7953 at 9/5/17 12:37 PM:
----------------------------------------------------------------
Hi Mike,
actually expressions already insert the expression text into the stack trace.
But this only happens when the compiled expression function is part of the
stack trace. We also have a test for this:
https://github.com/apache/lucene-solr/blob/8b055382d6c88acaed9fe472a038c7ee6b35c016/lucene/expressions/src/test/org/apache/lucene/expressions/js/TestCustomFunctions.java#L248-L267
The original expression's source code is presented as the "filename" in the
stack trace. This is only possible, because we generate the bytecode and it is
only visible if the executed code has the expression's generated class
somewhere in the trace.
Your example is different: The exception is happening inside the code that does
the setup of the expression and its ValueSources. We cannot hook inside that
easily (as the code is compiled by Javac). Instead, I would only suggest that
any exception thrown by the ExpressionValueSource's ctor maybe preserves the
expression as part of the message. The Expression abstract base class has the
source code, so we can use it the constructor of the ExpressionValueSource.
LTC is different as it modifies the stack trace after "catching" the expression
and then rethrows it. But this can only be done by the code that throws an
exception. And in that case it's better to preserve the code in the Message. Or
use a different sublass of RuntimeException, like ExpressionException.
was (Author: thetaphi):
Hi Mike,
actually expressions already insert the expression text into the stack trace.
But this only happens when the compiled expression function is part of the
stack trace. We also have a test for this:
https://github.com/apache/lucene-solr/blob/8b055382d6c88acaed9fe472a038c7ee6b35c016/lucene/expressions/src/test/org/apache/lucene/expressions/js/TestCustomFunctions.java#L248-L267
The original expression's source code is presented as the "filename" in the
stack trace. This is only possible, because we generate the bytecode and is
only visible if the code has the expression's generated class somewhere in the
source code.
Your example is different: The exception is happening inside the code that does
the setup of the expression and its ValueSources. We cannot hook inside that
easily (as the code is compiled by Javac). Instead, I would only suggest that
any exception thrown by the ExpressionValueSource's ctor maybe preserves the
expression as part of the message. The Expression abstract base class has the
source code, so we can use it the constructor of the ExpressionValueSource.
LTC is different as it modifies the stack trace after "catching" the expression
and then rethrows it. But this can only be done by the code that throws an
exception. And in that case it's better to preserve the code in the Message. Or
use a different sublass of RuntimeException, like ExpressionException.
> Can we include the expression string in the stack frame for problems
> evaluating Lucene expressions?
> ---------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7953
> URL: https://issues.apache.org/jira/browse/LUCENE-7953
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/expressions
> Reporter: Michael McCandless
> Priority: Minor
>
> I'm working with rather complex expressions to compute relevance, and when
> there is a problem, I see a stack trace like this:
> {noformat}
> Server error:
> java.lang.IllegalArgumentException: field "is_prime" has type bin, which
> cannot be used in an expression
> at
> com.amazon.lucene.Searcher$IndexBindings.getDoubleValuesSource(Searcher.java:373)
> at
> com.amazon.lucene.Searcher$QueryBindings.getDoubleValuesSource(Searcher.java:302)
> at
> org.apache.lucene.expressions.ExpressionValueSource.<init>(ExpressionValueSource.java:45)
> at
> org.apache.lucene.expressions.Expression.getDoubleValuesSource(Expression.java:97)
> at
> com.amazon.lucene.Searcher$IndexBindings.getDoubleValuesSource(Searcher.java:378)
> at
> com.amazon.lucene.Searcher$QueryBindings.getDoubleValuesSource(Searcher.java:302)
> at
> org.apache.lucene.expressions.ExpressionValueSource.<init>(ExpressionValueSource.java:45)
> at
> org.apache.lucene.expressions.Expression.getDoubleValuesSource(Expression.java:97)
> at
> com.amazon.lucene.Searcher$IndexBindings.getDoubleValuesSource(Searcher.java:378)
> at
> com.amazon.lucene.Searcher$QueryBindings.getDoubleValuesSource(Searcher.java:302)
> at
> org.apache.lucene.expressions.ExpressionValueSource.<init>(ExpressionValueSource.java:45)
> at
> org.apache.lucene.expressions.Expression.getDoubleValuesSource(Expression.java:97)
> at
> com.amazon.lucene.Searcher$IndexBindings.getDoubleValuesSource(Searcher.java:378)
> at
> com.amazon.lucene.Searcher$QueryBindings.getDoubleValuesSource(Searcher.java:302)
> at
> com.amazon.lucene.http.SearchA9Handler.handleInner(SearchA9Handler.java:459)
> at
> com.amazon.lucene.http.SearchA9Handler.handle(SearchA9Handler.java:99)
> at <server>
> {noformat}
> It's my code that's throwing the exception, but it would sure be nice if all
> the intermediate stack frames in the exception would include the expression
> text (or maybe some smallish prefix of it, in case it's gigantic), because I
> think here I have 3 levels of expression, and it'd be nice to know which
> sub-expressions, sub-sub-expressions, etc., led to the offensive {{is_prime}}
> field.
> I don't know how to do this, but e.g. I know our randomizedtesting lib is
> able to modify stack to insert test seeds, so it seems to be possible.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
