[
https://issues.apache.org/jira/browse/DRILL-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16017737#comment-16017737
]
ASF GitHub Bot commented on DRILL-5512:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/838#discussion_r117535728
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/ScanBatch.java
---
@@ -213,17 +213,16 @@ public IterOutcome next() {
try {
currentReader.allocate(mutator.fieldVectorMap());
} catch (OutOfMemoryException e) {
- logger.debug("Caught OutOfMemoryException");
clearFieldVectorMap();
- return IterOutcome.OUT_OF_MEMORY;
+ throw UserException.memoryError(e).build(logger);
}
addImplicitVectors();
} catch (ExecutionSetupException e) {
- this.context.fail(e);
--- End diff --
Throwing an exception, it turns out, does exactly the same: it cancels the
query and causes the fragment executor to cascade close() calls to all the
operators (record batches) in the fragment tree. It seems some code kills the
query by throwing an exception, other code calls the fail method and bubbles up
STOP. But, since the proper way to handle STOP is to unwind the stack, STOP is
equivalent to throwing an exception.
The idea is, rather than have two ways to clean up, let's standardize on
one. Since we must handle unchecked exceptions in any case, the exception-based
solution is the logical choice for standardization.
> Standardize error handling in ScanBatch
> ---------------------------------------
>
> Key: DRILL-5512
> URL: https://issues.apache.org/jira/browse/DRILL-5512
> Project: Apache Drill
> Issue Type: Improvement
> Affects Versions: 1.10.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
> Labels: ready-to-commit
> Fix For: 1.10.0
>
>
> ScanBatch is the Drill operator executor that handles most readers. Like most
> Drill operators, it uses an ad-hoc set of error detection and reporting
> methods that evolved over Drill development.
> This ticket asks to standardize on error handling as outlined in DRILL-5083.
> This basically means reporting all errors as a {{UserException}} rather than
> using the {{IterOutcome.STOP}} return status or using the
> {{FragmentContext.fail()}} method.
> This work requires the new error codes introduced in DRILL-5511, and is a
> step toward making readers aware of vector size limits.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
