[
https://issues.apache.org/jira/browse/CALCITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644441#comment-16644441
]
Hongze Zhang commented on CALCITE-525:
--------------------------------------
Hi [~julianhyde] and [~vlsi], thank you for the suggestions.
In the newest commit, I have made all new classes @Experimental, and made Util
class to be compliance with spec, and some other changes.
bq. You seem to handle each and every EnumerableCalc, however a single query
might have multiple EnumerableCalc instances. Does it really make sense to
handle all of them?
IMO, It is a little tricky to choose a place in which we put the
catch-and-handle logic, there are some possible choices:
1. Decorate the root enumerable returned from root bindable;
2. Decorate the inner enumerables (Just like the PR does);
3. Directly change the code generated by RexToLixTranslator#translateCall
(Maybe use a lambda to wrap the implemented expression).
1 is OK but some exceptions could not be caught in this way (E.g. when use
group by query);
3 needs a lot of test work since it changes generated code wildly, and we could
not easily implement "drop a row" only by changing the RexToLix code.
So I choose 2 in the PR.
bq. What sense log action means? What is the result of SQL when exception is
logged and/or ignored?
ExceptionHandlerEnum.LOG indicates "log the error and discard it". And
ExceptionHandlerEnum.DISCARD means "discard it". If the names are confusing, I
can give them a longer name maybe (E.g. ExceptionHandlerEnum.LOG_AND_DISCARD).
bq. Some of the strategy can occur at code-generation time (and could therefore
apply to engines other than Enumerable).
In the newest commit, I have made changes to ExceptionHandler to make it handle
exceptions only, rather than handling enumerable directly, so that the handler
could be used in anywhere.
> 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)
