[ 
https://issues.apache.org/jira/browse/CALCITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643796#comment-16643796
 ] 

Julian Hyde commented on CALCITE-525:
-------------------------------------

I saw [~vlsi]'s comments on the PR, but let's bring the discussion to this JIRA.

I do see why you want to add a public API - people need to customize how 
exceptions are handled. One person (or engine) might want to abort a query on 
divide-by-zero, another might want to convert it to null.

Some of the strategy can occur at code-generation time (and could therefore 
apply to engines other than Enumerable) but you are correct that we need some 
runtime support.

I like how you have created an ExceptionHandler class and added it to 
DataContext, and how you have created some default implementations in an enum. 
I would mark these APIs experimental using annotations, as [~vlsi] suggests.

Can you rename ExceptionHandlerUtil to ExceptionHandlers, per current 
conventions for companion objects.

Thanks for the comprehensive tests.

I'll do a detailed review when we have achieved consensus on the specification.

> 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)

Reply via email to