[
https://issues.apache.org/jira/browse/PHOENIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566983#comment-15566983
]
ASF GitHub Bot commented on PHOENIX-3345:
-----------------------------------------
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/215#discussion_r82912355
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1115,4 +1115,15 @@ public static Object convertSqlLiteral(SqlLiteral
literal, PhoenixRelImplementor
+ " to its object type.", ex);
}
}
+
+ public static SQLException unwrapSqlException(SQLException root){
+ Exception e = root;
+ while(e.getCause() != null){
+ e = (Exception) e.getCause();
+ if(e instanceof SQLException){
+ root = (SQLException) e;
+ }
+ }
+ return root;
+ }
--- End diff --
Yes, we'd definitely want to catch RuntimeException and look for a nested
SQLException. I'd stop at the first SQLException we find and throw that one.
> SQLException code's not propagating as expected
> -----------------------------------------------
>
> Key: PHOENIX-3345
> URL: https://issues.apache.org/jira/browse/PHOENIX-3345
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Eric Lomore
> Assignee: Eric Lomore
> Attachments: variablestate.png
>
>
> Perhaps this is intended by Calcite, but when errors are thrown by execute()
> functions the error code that is initially thrown (say 1000) does not make
> its way to the final SQLException on top.
> This is prevalent in multiple tests throughout QueryCompilerTest.java. One
> such example is included below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
