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

["Daniel Barclay (Drill) (JIRA)" <ji...@apache.org>]

     [ 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)