[
https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616254#comment-15616254
]
ASF GitHub Bot commented on TINKERPOP-887:
------------------------------------------
GitHub user BrynCooke opened a pull request:
https://github.com/apache/tinkerpop/pull/470
TINKERPOP-887 ExceptionHandlerStrategy
Added exception handler strategy to convert FastNoSuchElementExceptions in
to regular NoSuchElementExceptions when exiting a traversal.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-887
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/470.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #470
----
commit 4b80bcd2f12b905a927d61e257c2d4b00f76f609
Author: BrynCooke <[email protected]>
Date: 2016-10-28T19:04:10Z
TINKERPOP-887 Added exception handler strategy to convert
FastNoSuchElementExceptions in to regular NoSuchElementExceptions when exiting
a traversal.
----
> FastNoSuchElementException hides stack trace in client code
> -----------------------------------------------------------
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.2-incubating
> Reporter: Bryn Cooke
> Assignee: Marko A. Rodriguez
> Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return
> an element, but it didn't. The surprise was that I got no stack trace and
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional
> circumstances then why is a singleton is used over a normal exception with
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it
> shouldn't. Code should check hasNext rather than trying for next and dealing
> with an exceptional result. I'm not sure what the current state of things are
> in the JVM but at least in the past try catch blocks would inhibit
> optimization even without stack traces so this type of code was considered an
> antipattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
