[jira] [Commented] (DRILL-6098) Make Drill Failure Handling Consistent

["Paul Rogers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DRILL-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16331604#comment-16331604 ] 

Paul Rogers commented on DRILL-6098:
------------------------------------

Thanks for taking on this task! Posted a design document from an earlier attempt in case if offers any useful ideas.

> Make Drill Failure Handling Consistent
> --------------------------------------
>
>                 Key: DRILL-6098
>                 URL: https://issues.apache.org/jira/browse/DRILL-6098
>             Project: Apache Drill
>          Issue Type: Improvement
>            Reporter: Timothy Farkas
>            Assignee: Timothy Farkas
>            Priority: Major
>         Attachments: Drill Operator Error Handling Redesign.pdf
>
>
> As described by [~Paul.Rogers]
> "
> We have multiple ways of reporting errors:
>  * Throw a UserException explaining the error
>  * Throw an unchecked exception and and let the fragment executor guess the cause.
>  * Return STOP
>  * Tell the fragment executor to fail. (A we also required to return STOP?)
>  * Return OUT_OF_MEMORY status
> The proposal is to replace them all with a single solution: throw a UserException. Each operator catches other exceptions and translates them to UserException.
> Java unwinds the stack just fine; no reason for us to write code to do it via STOP.
> Then, the Fragment Executor calls close() on all operators. No reason to try to do this cleanup on STOP. (Even if we do, the lower-level operators won't have seen the STOP.)
> Since failures are hard to test, and have cause no end of problems, having multiple ways to do the same thing is really not that helpful to Drill users.
> "



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)