[ 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 7:45 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 '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. 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 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)