Bryn Cooke created TINKERPOP3-887:
-------------------------------------
Summary: FastNoSuchElementException hides stack trace in client
code
Key: TINKERPOP3-887
URL: https://issues.apache.org/jira/browse/TINKERPOP3-887
Project: TinkerPop 3
Issue Type: Bug
Components: process
Affects Versions: 3.0.1-incubating
Reporter: Bryn Cooke
Assignee: Marko A. Rodriguez
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)
