[
https://issues.apache.org/jira/browse/DRILL-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2662:
------------------------------------------
Description:
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)).
> 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
> Reporter: Daniel Barclay (Drill)
>
> 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)
