[
https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616690#comment-15616690
]
Bryn Cooke commented on TINKERPOP-887:
--------------------------------------
Is this really going to make a difference to performance? The added step is
basically a no-op, so unless there is definitely a performance degradation then
it'd be better to avoid the extra complexity for users having to enable a
special mode. Perhaps we can evaluate the perf impact before going down this
route?
If we did have to have a special mode then how would this be activated?
Say you have a 100 line gremlin script that you are submitting to gremlin
server, you'd want to enable this mode for all traversals in the request. That
way when the error occurs you can tell which line it occurred on. Perhaps
[~spmallette] has some ideas? Ideally I would like to avoid having to put the
entire server in to debug mode.
> 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)
