drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deneche A. Hakim (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (DRILL-2662) Exception type not being included when propagating exception message
Date Fri, 15 May 2015 18:10:01 GMT

     [ https://issues.apache.org/jira/browse/DRILL-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Deneche A. Hakim resolved DRILL-2662.
    Resolution: Fixed

> 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

View raw message