[
https://issues.apache.org/jira/browse/LUCENE-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated LUCENE-6965:
------------------------------------------
Attachment: LUCENE-6965.patch
bq. why the intermediate exception?
I couldn't find a better way to propagate the exception. Throwing
ParseException from the visitor can't be done, since the visitor is called from
RuleContext.accept, which doesn't throw any exceptions.
I wouldn't want to catch a general IllegalArgumentException to convert it to
ParseException, something unexpected inside visitor.visit could throw an
IllegalArgumentException and I don't want to change the type of that.
bq. Also, it looks like you are losing stack frames when creating a new
exception from the intermediate.
Yes, unfortunately the ParseException doesn't support providing a cause in the
constructor. I can add the cause by using: {{exception.initCause(e);}}.
Attached new patch with this change and made the intermediate exception static
> Expression's JavascriptCompiler to throw ParseExceptions with bad function
> names or arity
> -----------------------------------------------------------------------------------------
>
> Key: LUCENE-6965
> URL: https://issues.apache.org/jira/browse/LUCENE-6965
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Tomás Fernández Löbbe
> Attachments: LUCENE-6965.patch, LUCENE-6965.patch
>
>
> Currently JavascriptCompiler will throw IllegalArgumentException for bad
> function names (or functions that don't exist) and for bad arity. I can see
> why this was done this way, but I believe ParseException would also be
> correct and it would be better since that's the exception clients will be
> prepared to receive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
