[jira] [Commented] (TINKERPOP-887) FastNoSuchElementException hides stack trace in client code

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ 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 <br...@gmail.com>
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)