[
https://issues.apache.org/jira/browse/DRILL-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deneche A. Hakim updated DRILL-2662:
------------------------------------
Fix Version/s: (was: 0.9.0)
1.0.0
> 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.0.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)
