[
https://issues.apache.org/jira/browse/CALCITE-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623404#comment-16623404
]
Julian Hyde edited comment on CALCITE-2535 at 9/21/18 6:15 PM:
---------------------------------------------------------------
[~julianhyde]
Sorry for late reply, and I found an existing issue CALCITE-525 about function
error handling, Could we use that issue directly?
bq. Any idea when you will get to it?
If I could have chance to solve this, I think I can get start with it just
after 2 or 3 days.
Here is a possible fix plan:
1. To create an CalciteSQLException.java(or some other good name) extending the
existing super class CalciteException.java, the CalciteException.java is a
RuntimeException rather than a checked exception;
2. To use CalciteResource.java to summarize error messages and error codes of
the CalciteSQLException;
3. To format the CalciteSQLException#message to show represent error code(SQL
state).
4. To provide a switchable option to make Calcite suppress CalciteSQLException
thrown from builtin functions. (Maybe return null when there are errors)
Something not perfect:
This will only available from functions registered to RexImpTable.java, because
the change is about to be inside RexToLixTranslator#translateCall, but some
operators is implemented individually (See last line of
RexImpTable.BinaryImplementor#implement), we could not catch the exceptions.
Would you please let me know if there is any wrong direction or any
optimization possibility about the plan?
was (Author: zhztheplayer):
[~julianhyde]
Sorry for late reply, and I found an existing issue
[Issue#535|https://issues.apache.org/jira/browse/CALCITE-525] about function
error handling, Could we use that issue directly?
bq. Any idea when you will get to it?
If I could have chance to solve this, I think I can get start with it just
after 2 or 3 days.
Here is a possible fix plan:
1. To create an CalciteSQLException.java(or some other good name) extending the
existing super class CalciteException.java, the CalciteException.java is a
RuntimeException rather than a checked exception;
2. To use CalciteResource.java to summarize error messages and error codes of
the CalciteSQLException;
3. To format the CalciteSQLException#message to show represent error code(SQL
state).
4. To provide a switchable option to make Calcite suppress CalciteSQLException
thrown from builtin functions. (Maybe return null when there are errors)
Something not perfect:
This will only available from functions registered to RexImpTable.java, because
the change is about to be inside RexToLixTranslator#translateCall, but some
operators is implemented individually (See last line of
RexImpTable.BinaryImplementor#implement), we could not catch the exceptions.
Would you please let me know if there is any wrong direction or any
optimization possibility about the plan?
> Runtime failure check not working in SqlTesterImpl.java
> -------------------------------------------------------
>
> Key: CALCITE-2535
> URL: https://issues.apache.org/jira/browse/CALCITE-2535
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Hongze Zhang
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.18.0
>
>
> Problem at SqlTesterImpl#checkFails:
> When argument "runtime" is specified as true, error assertion and error
> message matching will not be performed.
> This issue could result in wrong test result in SqlOperatorBaseTest.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
