ASF GitHub Bot commented on PHOENIX-3345:

Github user lomoree commented on a diff in the pull request:

    --- 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

Reply via email to