[ 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: 1.1.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)