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