Uploaded image for project: 'Apache Drill'
  1. Apache Drill
  2. DRILL-2662

Exception type not being included when propagating exception message

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 0.8.0
    • 1.0.0
    • Execution - Flow
    • None

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

      Attachments

        Issue Links

          Activity

            People

              adeneche Abdel Hakim Deneche
              dsbos Daniel Barclay
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: