[
https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617713#comment-15617713
]
Bryn Cooke commented on TINKERPOP-887:
--------------------------------------
OK. That makes sense. I had issues with an interaction with the other
strategies that were painful to resolve. I can see that adding new strategies
is last resort.
Taking a step back I have modified the PR so that strategies are not touched.
It's much simpler. Please could you take another look?
I added a basic test that checks that a traversal will throw
NoSuchElementException rather than FastNoSuchElementException. This
demonstrates the benefit in non-gremlin server scenarios.
In future Gremlin Server can use this information to supply line precise error
reporting, but that is outside the scope of this ticket.
If there are more tests that you would like adding please can you point me to
the package where you would see them residing?
> 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)
