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

["Bryn Cooke (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryn Cooke reopened TINKERPOP-887:
----------------------------------

Please could you take a look at the PR and see if it has any potential?
It adds a new strategy that appends a final step to top level traversals that converts any FastNoSuchElementException in to a regular NoSuchElementException. It means that we don't get the stack trace in to the traversal, but clients do get information about where in their code the exception was thrown.

> 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)