[
https://issues.apache.org/jira/browse/CALCITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651127#comment-16651127
]
Hongze Zhang edited comment on CALCITE-525 at 10/16/18 9:05 AM:
----------------------------------------------------------------
Hi [~julianhyde] and [~vladimirsitnikov],
Thanks for the concern about this issue, and I have read all your comments.
I wonder if we could start from "catch error from a RexCall", because if we
want to drop a row when error happens, it is not that easy to judge which row
should be dropped and which row should be reserved in Calcite.
I personally prefer to make Calcite return an empty or specified value when a
RexCall failed, like what I have described about a "CATCH_ERROR" function. I
hope you could take a look at [a nother
work|https://github.com/zhztheplayer/calcite/commits/525-3]. The work contains
following:
1. A 'CATCH_ERROR(... (EMPTY | ERROR) ON ERROR)' function and implementation;
2. A 'ERROR_MODE' option for Calcite connection: if the 'ERROR_MODE' is
'RETURN_EMPTY_VALUE', Calcite's converter will automatically wrap every rex
call with a 'CATCH_ERROR' call.
By having this feature, calcite adaptors can also implement 'CATCH_ERROR' in
their own rex implementation to use 'ERROR_MODE' feature.
Also, you can see an issue from HIVE.
was (Author: zhztheplayer):
Hi [~julianhyde] and [~vladimirsitnikov],
Thanks for the concern about this issue, and I have read all your comments.
I wonder if we could start from "catch error from a RexCall", because if we
want to drop a row when error happens, it is not that easy to judge which row
should be dropped and which row should be reserved in Calcite.
I personally prefer to make Calcite return an empty or specified value when a
RexCall failed, like what I have described about a "CATCH_ERROR" function. I
hope you could take a look at [a nother
work|https://github.com/zhztheplayer/calcite/commits/525-3]. The work contains
following:
1. A 'CATCH_ERROR(... (EMPTY | ERROR) ON ERROR)' function and implementation;
2. A 'ERROR_MODE' option for Calcite connection: if the 'ERROR_MODE' is
'THROW_ERROR', Calcite's converter will automatically wrap every rex call with
a 'CATCH_ERROR' call.
By having this feature, calcite adaptors can also implement 'CATCH_ERROR' in
their own rex implementation to use 'ERROR_MODE' feature.
Also, you can see an [issue|https://issues.apache.org/jira/browse/HIVE-5438]
from HIVE.
> Exception-handling in built-in functions
> ----------------------------------------
>
> Key: CALCITE-525
> URL: https://issues.apache.org/jira/browse/CALCITE-525
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Hongze Zhang
> Priority: Major
>
> The standard calls for certain built-in functions to throw exceptions.
> Examples:
> * 1 / 0
> * MOD(1, 0)
> * OVERLAY('foo' PLACING 'x' FROM -1)
> * 'x' NOT LIKE 'x' ESCAPE 'x'
> First, these exceptions should occur at run time. They should cause the
> current value to become null, or the row to be omitted, but should not abort
> the query. (Actual behavior TBD.)
> Second, EnumerableCalc does constant reduction and generates code like
> 'static final int X = 0 / 0'. This code blows up when the class is loaded. It
> should not. The code should give errors for each row, as described above.
> While fixing this bug, see SqlOperatorBaseTest.testArgumentBounds and remove
> restrictions related to /, MOD and OVERLAY, LIKE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
