[
https://issues.apache.org/jira/browse/PHOENIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15543385#comment-15543385
]
James Taylor commented on PHOENIX-3345:
---------------------------------------
Take a look at PhoenixStatement.java, this method:
{code}
protected PhoenixResultSet executeQuery(final CompilableStatement stmt)
throws SQLException {
...
} catch (RuntimeException e) {
// FIXME: Expression.evaluate does not throw
SQLException
// so this will unwrap throws from that.
if (e.getCause() instanceof SQLException) {
throw (SQLException) e.getCause();
}
throw e;
} finally {
{code}
We'll need need to do something similar in Phoenix/Calcite.
> 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)
