[
https://issues.apache.org/jira/browse/DRILL-5057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684404#comment-15684404
]
Paul Rogers commented on DRILL-5057:
------------------------------------
Right, but that is rather the point. There are many places that need to do
proper clean-up and state transitions. By having the exception be unchecked, it
is easy to omit the required clean-up. A checked exception forces the developer
to think about whether clean-up is needed.
Agree that a simple switch of base classes would cause a large number of
changes to occur all at once. This is why the proposed solution is too change
gradually: create a new {{buildChecked( )}} method that returns a checked
exception. Use that when working in an area where we need to think about proper
clean-up. Leave others unchanged until we have time to revisit.
Otherwise, we are saying that proper clean-up is required, but folks are on
their own to figure out when to catch UserException & do the cleanup...
The alternative is to require that all code catch {{Throwable}}, which is would
also be a fine (if messy) solution.
Perhaps a better way to state this issue is: how do we ensure proper cleanup is
done for unchecked exceptions? Suggestions?
> UserException is unchecked, but is the primary way to report errors
> -------------------------------------------------------------------
>
> Key: DRILL-5057
> URL: https://issues.apache.org/jira/browse/DRILL-5057
> Project: Apache Drill
> Issue Type: Improvement
> Affects Versions: 1.8.0
> Reporter: Paul Rogers
> Priority: Minor
>
> Java provides two flavors of exceptions: checked and unchecked. Checked
> exceptions must be declared by any method that can throw them:
> {code}
> public void foo( ) throws ACheckedException ...
> {code}
> Unchecked exceptions derive from Java's {{RuntimeException}} class and do not
> need such a declaration. Unchecked exceptions are supposed to handle
> program-error kinds of conditions: illegal states, array out of bounds -- the
> kind of thing that would clutter the code for errors that should never occur
> in working code. (See the [Java
> docs|https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html].)
> Drill's {{UserException}} class is the primary way to report that something
> went wrong. As a result, every operator should catch the exception and do
> necessary clean-up and termination. Yet, the exception is unchecked.
> To ensure proper clean-up, migrate {{UserException}} to be checked. To help
> the migration, perhaps define a new {{ExecutionException}} class that is
> checked, along with a new {{buildChecked}} method in the "builder". Then,
> over time, migrate all user exceptions to the new, checked version and ensure
> that proper cleanup is done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
