[
https://issues.apache.org/jira/browse/CALCITE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957608#comment-14957608
]
Julian Hyde commented on CALCITE-645:
-------------------------------------
IIRC, JDBC has the concept of a causal chain (which all Java exceptions now
have) and it also has the concept of a list of exceptions not related to each
other. The typical use case for the latter is warnings about rows rejected
during a load, or rows that had arithmetic exceptions during query processing.
I think of SQLException.getCause() as an "upwards" link and
SQLException.getNextException() as as "sideways" link. The chain of exceptions
by getNextException() must all be instances of SQLException.
I would ignore for now the possibility that the cause of a SQLException is
itself a SQLException that is part of a chain. Thus the structure looks like
this:
{noformat}
e1c2 e3c2
| |
e1c1 e3c1 e4c1
| | |
e1 ------ e2 ------ e3 ------ e4
{noformat}
I think I'd model the chain of exceptions from a statement as a list of
exceptions, and each exception has a "cause" field which is either null or a
serialized copy of the getCause() exception.
> Pass server-side exceptions back to the client
> ----------------------------------------------
>
> Key: CALCITE-645
> URL: https://issues.apache.org/jira/browse/CALCITE-645
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Nick Dimiduk
> Assignee: Josh Elser
>
> Avatica RPC response objects should contain an exception field that can be
> deserialized and re-thrown on the client side. That way client sees stack
> traces that are more meaningful than "500 error".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
