[jira] [Commented] (DRILL-2662) Exception type not being included when propagating exception message

["Deneche A. Hakim (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DRILL-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14545902#comment-14545902 ] 

Deneche A. Hakim commented on DRILL-2662:
-----------------------------------------

on 1.0.0 the message does include the class name when it's a system error, here is an example of error message I got:
{noformat}
0: jdbc:drill:zk=local> select * from dfs.data.`2662.json`;
+-------+
|   a   |
+-------+
| col4  |
+-------+
1 row selected (0.1 seconds)


0: jdbc:drill:zk=local> select cast(a as int) from dfs.data.`2662.json`;
Error: SYSTEM ERROR: java.lang.NumberFormatException: col4

Fragment 0:0

[Error Id: 6a4a86dd-8611-4414-ae28-8c6473a4c741 on abdel-11.qa.lab:31010] (state=,code=0)
0: jdbc:drill:zk=local> 
{noformat}

> Exception type not being included when propagating exception message
> --------------------------------------------------------------------
>
>                 Key: DRILL-2662
>                 URL: https://issues.apache.org/jira/browse/DRILL-2662
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Execution - Flow
>    Affects Versions: 0.8.0
>            Reporter: Daniel Barclay (Drill)
>            Assignee: Deneche A. Hakim
>             Fix For: 1.1.0
>
>
> A query that tries to cast a non-numeric string (e.g., "col4") to an integer fails (as expected), with the root exception being a NumberFormatException whose exception trace printout would begin with:
>   java.lang.NumberFormatException: "col4"
> However, one of the higher-level chained/wrapping exceptions shows up like this:
>   Query failed: RemoteRpcException: Failure while running fragment., "col4" [ 99343f97-5c70-4454-b67f-ae550b2252fb on dev-linux2:31013 ]
> In particular, note that the most important information, that there was a numeric syntax error, is not present in the message, even though some details (the string with the invalid syntax) is present.
> This usually comes from taking getMessage() of an exception rather than toString() when making a higher-level message.
> The toString() method normally includes the class name--and frequently the class name contains key information that is not given in the exception message.  (Maybe Sun/Oracle should have always put the full information in the message part, but they didn't.)
> _If_ all our exceptions were just for developers, then I'd suggest always wrapping exceptions like this:
>   throw new WrappingException( "higher-level problem: " + e, e );
> rather than
>   throw new WrappingException( "higher-level problem: " + e.getMessage(), e );
> to avoid losing information.  (Then the top-most exception's message string always includes all the information from the lower-level exception's message strings.)
> However, since that would inject class names (irrelevant to users) into message strings (shown to users), for Drill we should probably make sure that exceptions like NumberFormatException (for expected conversion errors) are always wrapped in or replaced by exceptions that are meant for users (e.g., an InvalidIntegerFormatDataException (from standard SQL exception conditions like "data exception — invalid datetime format") whose message string stands on its own (independent of whether the class name appears with it)).  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)