[
https://issues.apache.org/jira/browse/TINKERPOP-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493744#comment-15493744
]
Matthias Broecheler commented on TINKERPOP-1450:
------------------------------------------------
I think both of these suggestions are great ideas since they address different
needs:
1) Addresses the novel user who might write a traversal such as
{{g.V().outE().next()}} and end up with a stack-less exception that doesn't
make sense to them.
2) Addresses the "application development" need where TinkerPop code is used
throughout an app. Changing the behavior with a system property is fine in this
case. The fact that this doesn't work for production systems where Gremlin code
is send over the wire or somehow executed remotely isn't a problem imho, since
those cases typically don't have a ton of complicated (i.e. 1000s lines of)
code and 1) above should take care of most needs.
> Add support for stack trace filling to FastNoSuchElementException
> -----------------------------------------------------------------
>
> Key: TINKERPOP-1450
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1450
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.3, 3.2.2
> Reporter: Marko A. Rodriguez
>
> Many people (like [~mbroecheler]) complain that if they have some complicated
> code they don't know where the problem is when a traversal throws a
> {{FastNoSuchElementException}}. I think we can remedy this in on of two ways:
> 1.) Only the root traversal will "fill in the stack trace" if there is no
> such element. This way, a stack trace is filled once and only once. However,
> the problem here is that the user will only know that the traversal failed,
> not where in the traversal it failed.
> 2.) Provide a "is.testing" System.getProperty() to
> {{FastNoSuchElementException}}. The problem here, this will only show stack
> traces for code that is executed in the same JVM as Gremlin's. This is great
> for actually testing (JUnit style), but not for production settings.
> 3.) ... dunno? Anyone have an idea?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
