[ 
https://issues.apache.org/jira/browse/TINKERPOP3-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957011#comment-14957011
 ] 

Bryn Cooke commented on TINKERPOP3-887:
---------------------------------------

Possibly, although it doesn't help for production deployments. Imagine a log 
file full of FastNoSuchElementException messages but no clue as to where they 
are being generated.
Would it be possible to convert FastNoSuchElementException to a regular 
NoSuchElementException as it exits gremlin code? The user won't get a stack 
trace right down in to the depths of the the traversal, but at least they'll 
know which line in their code the error occurred on.

> FastNoSuchElementException hides stack trace in client code
> -----------------------------------------------------------
>
>                 Key: TINKERPOP3-887
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-887
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.1-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)

Reply via email to