Making division by zero return null is actually a very different task from handling exceptions. It fits nicely within the SQL model of functions without side effects.
There is an issue open assigned to me to provide an example of such an operator: https://issues.apache.org/jira/browse/CALCITE-7270 This has been through several scope/design iterations. I have implemented this previously in our compiler using the following mechanism: - define a SAFE_DIVIDE operator (a RexNode) - type inference is similar to DIV, except the result is always nullable, even for non-null arguments - implement the runtime functions implementing it, which return NULL at runtime on division by zero - create a visitor which replaces all integer division operators DIV with SAFE_DIVIDE This worked pretty well, and it didn't really need any changes to Calcite core. My plan for 7270 was to create a similar "demo" implementation, but I got sidetracked with other tasks. Mihai ________________________________ From: [email protected] <[email protected]> Sent: Thursday, April 30, 2026 3:56 AM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] SQL-level error handling semantics in Calcite Hello, we had a related discussion some months ago about how to handle division-by-zero. I had created a ticket, which includes some links to discussions on the mailing list: https://issues.apache.org/jira/browse/CALCITE-7264 I would appreciate if it would be possible to configure Calcite in a way that division-by-zero to be a valid expression evaluating to NULL. It would be nice to make the design general enough to allow defining the behavior of errors/exceptions either globally or at the statement level, depending on the expression that causes the error. Kind regards, Thomas On 4/24/26 7:15 PM, Mihai Budiu <[email protected]> wrote: > To a large degree this is a problem of the runtime. Calcite comes with a > runtime, but you are not obliged to use it, you can implement your own > runtime which behaves differently. > > But I think your question is about language features supporting error > handling - and these do pertain to the compiler. > > Semantics is very subtle, and designing such features of a programming > language is a delicate act. > That's why in general I prefer to avoid designing new features in favor of > reusing existing time-tested designs. > What is missing from this description is a short survey of how other > mainstream databases and streaming systems handle errors. Ideally, we can > adopt a good existing design, or perhaps a mix of features from existing > designs. > > Mihai > > > ________________________________ > From: FeatZhang <[email protected]> > Sent: Friday, April 24, 2026 4:55 AM > To: [email protected] <[email protected]> > Subject: [DISCUSS] SQL-level error handling semantics in Calcite > > Hi Calcite devs, > > I would like to start a discussion around *error handling semantics at SQL > statement level* in Calcite. > ------------------------------ > 1. Background > > In modern data processing systems (both batch and streaming), handling > malformed or partially invalid data is a common requirement. > > Typical issues include: > > - malformed JSON / structured payloads > - type mismatches during casting > - schema evolution inconsistencies > - runtime exceptions in user-defined functions > > Currently, Calcite provides limited support for error handling via: > > - expression-level constructs (e.g., TRY_CAST) > - NULL propagation semantics > > However, these approaches are limited to *expression-level error tolerance*. > ------------------------------ > 2. Problem Statement > > There is currently no way to express *statement-level error handling > semantics* in SQL within Calcite. > > Specifically: > 2.1 No abstraction beyond expression level > > Error handling must be embedded into individual expressions: > > TRY_CAST(col AS INT) > > This leads to: > > - verbose queries > - duplicated logic > - lack of composability > > ------------------------------ > 2.2 No structured error propagation > > There is no way to: > > - capture error context > - classify errors > - propagate error metadata alongside query execution > > ------------------------------ > 2.3 No extensibility for downstream systems > > Many systems built on Calcite (e.g., streaming engines, data processing > frameworks) require more advanced error handling capabilities, but > currently must implement them outside SQL. > ------------------------------ > 3. Discussion Proposal > > I would like to explore whether Calcite should support a more general > abstraction for error handling at SQL level. > > Some possible directions: > ------------------------------ > Option A: Statement-level TRY semantics > > SELECT * > FROM TRY(source_table) > > Semantics: > > - failed records are skipped or handled based on policy > > ------------------------------ > Option B: Error handling clause (conceptual) > > SELECT * > FROM source_table > HANDLE ERRORS WITH <policy> > > Where <policy> could define: > > - ignore > - nullify > - propagate > - custom handling > > ------------------------------ > Option C: Error-aware relational operator > > Introduce a logical abstraction such as: > > ErrorHandlingRelNode > > Which could: > > - wrap existing RelNodes > - attach error metadata > - allow downstream systems to interpret error semantics > > ------------------------------ > 4. Key Questions > > I would appreciate feedback on: > > 1. Should Calcite support error handling beyond expression-level? > 2. Is there prior discussion or design work in this area? > 3. Would a logical operator (instead of SQL syntax) be more appropriate? > 4. How should this interact with relational algebra assumptions (single > output, determinism)? > 5. Should Calcite remain minimal and leave this entirely to downstream > systems? > > ------------------------------ > 5. Motivation > > The goal is not to introduce engine-specific features, but to explore > whether Calcite should provide a *generic abstraction layer* for error > handling that downstream systems can leverage. > ------------------------------ > Closing > > I am interested in hearing thoughts on whether this direction aligns with > Calcite’s design goals, and whether such an extension would be considered > in scope. > > Thanks! > >
