[
https://issues.apache.org/jira/browse/PHOENIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568954#comment-15568954
]
ASF GitHub Bot commented on PHOENIX-3345:
-----------------------------------------
Github user lomoree commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/215#discussion_r83024234
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1120,8 +1120,11 @@ public static SQLException
unwrapSqlException(SQLException root){
Exception e = root;
while(e.getCause() != null){
e = (Exception) e.getCause();
+ if(e instanceof RuntimeException && e.getCause() instanceof
SQLException) {
--- End diff --
Latest changes attempt to locate the nested SQLException within an
RuntimeException. We still throw the first SQLException seen in case there's no
wrapping argument exception. And if no matches are found, we throw the root so
as to avoid unexpected behavior.
> 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)
