[GitHub] [calcite] xwkuang5 commented on a change in pull request #2312: [CALCITE-4265] Improve error message when CAST to unknown type (Louis…

[GitBox <gi...@apache.org>]

xwkuang5 commented on a change in pull request #2312:
URL: https://github.com/apache/calcite/pull/2312#discussion_r552327648



##########
File path: core/src/main/java/org/apache/calcite/sql/fun/SqlCastFunction.java
##########
@@ -93,6 +95,29 @@ public SqlCastFunction() {
 
   //~ Methods ----------------------------------------------------------------
 
+  @Override public void validateCall(final SqlCall call, final SqlValidator validator,
+      final SqlValidatorScope scope,
+      final SqlValidatorScope operandScope) {
+    try {
+      super.validateCall(call, validator, scope, operandScope);
+    } catch (UnsupportedOperationException ex) {
+      assert call.operandCount() == 2;
+      throw validator.newValidationError(call,
+          RESOURCE.cannotCastToType(call.operand(1).toString()));
+    }
+  }
+
+  @Override public RelDataType deriveType(final SqlValidator validator,
+      final SqlValidatorScope scope, final SqlCall call) {
+    try {
+      return super.deriveType(validator, scope, call);
+    } catch (UnsupportedOperationException ex) {
+      assert call.operandCount() == 2;
+      throw validator.newValidationError(call,
+          RESOURCE.cannotCastToType(call.operand(1).toString()));

Review comment:
       You are right, I think it should. 
   
   However, I found that incorporating the cause will make this a much larger change than it is right now. Currently, `SqlValidator` interface only has a `newValidationError` method that takes an `ExInst`, which represents an exception without cause. We can add a new method `newValidationErrorWithCause` to the `SqlValidator` interface. There will need to be some refactoring for `SqlUtil.newContextException` as well. Note that hacking this by adding `initCause` to the resulting exception returned from `newValidationError` does not work because the exception has already been initialized with a cause during construction.
   
   Overall, I think this can be split into a refactoring commit + this commit. I think the combined LOC will be  >100. Not sure if the extra code added and refactoring is worth the benefit: on one hand, having the cause provides better context. On the other hand, the cast function is not that complicated `CAST(value as type)` and the current exception message might be enough for debugging.
   
   What do you think?




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org