drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DRILL-5178) Overuse of SchemaChangeException
Date Sun, 08 Jan 2017 02:03:58 GMT
Paul Rogers created DRILL-5178:

             Summary: Overuse of SchemaChangeException 
                 Key: DRILL-5178
                 URL: https://issues.apache.org/jira/browse/DRILL-5178
             Project: Apache Drill
          Issue Type: Bug
    Affects Versions: 1.9.0
            Reporter: Paul Rogers
            Priority: Minor

Drill code overuses the {{SchemaChangeException}} exception. This exception is thrown any
time that code attempts to allocate or access a value vector. It causes all generated methods
to throw the exception, all templates to declare the exception, and all operators to handle
the exception.

The only problem is that, semantically, where the code is called that throws the exception
can never actually encounter this exception. That is, in most cases, code elsewhere has already
handled actual schema changes; where the exception is thrown is only a theoretical possibility.
But, since schema changes are actually handled elsewhere, it is a coding error if the {{SchemaChangeException}}
is thrown deep in the code.

Since the exception in these cases is a coding error, the exception thrown should be unchecked,
something like {{IllegalArgumentException}} or {{IllegalStateException}}.

Said another way, the design of Drill should be that each operator properly handles a schema
change as reported from upstream. If the operator fails to handle the schema change, and the
code encounters a problem when accessing or allocating a vector, this is not a schema change,
this is a programming error.

Better to allow the programmer to focus on real issues (actual schema change) than to muddy
the picture with constant, irrelevant potential schema changes.

Most code that receives such exceptions turns around and throws an unchecked illegal state
exception anyway, so we are not buying anything other than creating a mess.

This message was sent by Atlassian JIRA

View raw message