[
https://issues.apache.org/jira/browse/DRILL-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603410#comment-16603410
]
ASF GitHub Bot commented on DRILL-6724:
---------------------------------------
paul-rogers commented on issue #1455: DRILL-6724: Convert IndexOutOfBounds
exception to UserException with …
URL: https://github.com/apache/drill/pull/1455#issuecomment-418465629
@arina-ielchiieva, very good point. Having that information is very useful
regardless of the source of error. How could we provide that generically
without the need to wrap each bit of code in a "in case something goes wrong"
try/catch block? For example, suppose we get an NPE or OOM. Should we catch all
those?
Could each operator (including scanners) provide a context which can be
dumped to the log along with the stack trace? Often, we try to recreate the
fragment operators from the stack trace. Would be better to see a stack of
operators, each with it's critical info.
The fragment exec walks the operator tree to shut down each operator. I
could also do so to create the operator stack with related info.
Is this something we could consider? Would have been very helpful the many
times I tried to track down a failure found in a QA test or user case.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Convert IndexOutOfBounds exception to UserException with context data where
> possible
> ------------------------------------------------------------------------------------
>
> Key: DRILL-6724
> URL: https://issues.apache.org/jira/browse/DRILL-6724
> Project: Apache Drill
> Issue Type: Improvement
> Affects Versions: 1.14.0
> Reporter: Bohdan Kazydub
> Assignee: Bohdan Kazydub
> Priority: Major
> Fix For: 1.15.0
>
>
> Sometimes when IndexOutOfBoundsException is exposed to users it is not clear
> what causes the problem. Instead this exception may be converted to a more
> useful UserException containing context data like filename, line, position
> etc (depending on what is available from a reader for a given type).
> A possible approach is to add a method to a RecordReader interface which
> produces UserException of type ErrorType.DATA_READ with context data, so that
> when such an UserException is needed it can be easily obtained by invoking
> the method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
