You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Paul Rogers (JIRA)" <ji...@apache.org> on 2017/01/08 02:03:58 UTC
[jira] [Created] (DRILL-5178) Overuse of SchemaChangeException
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
(v6.3.4#6332)