[
https://issues.apache.org/jira/browse/PHOENIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566961#comment-15566961
]
ASF GitHub Bot commented on PHOENIX-3345:
-----------------------------------------
Github user maryannxue commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/215#discussion_r82879380
--- 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 --
Thanks for the modification, @lomoree! It think it's fine to go for the
deepest SQLException. But meanwhile I'm not sure if we should catch
RuntimeException as well and then either unwrap it if we can find an inner
SQLException or wrap it if not. @JamesRTaylor Any idea?
> 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)
