Hi Florian, This seems to be one of those issues where all the choices are somewhat undesirable. Doing nothing in 3.6/3.7 leaves us with a break between .NET 7 and 8. Standardising on nulls requires breaking existing .NET 8 users, and standardising on exceptions will break users of .NET 7 and below. I don’t have a strong preference on which path we choose for 3.6/3.7 as long as we document it as best as we can to try and prevent any surprises to users.
I agree that long term, the correct behaviour is to throw an exception when there are no elements left in order to be consistent with the other GLVs. Thanks, Cole From: Florian Hockmann <[email protected]> Date: Tuesday, April 23, 2024 at 5:43 AM To: [email protected] <[email protected]> Subject: [DISCUSS] Breaking change in Gremlin.Net's traversal enumeration if no element found (TINKERPOP-3072) Hi, Gremlin.Net currently behaves differently if, e.g., Next() is called on a traversal that has no (more) results for .NET 8 than for earlier .NET versions. It returns null for earlier .NET versions but throws an exception on .NET 8. (This is tracked in TINKERPOP-3072 <https://issues.apache.org/jira/browse/TINKERPOP-3072> .) A minimal example to better illustrate what I'm talking about: g.V().Has("Name", "doesnotexist").Next(); Result: On .NET 7 and earlier: null On .NET 8: System.InvalidOperationException: Enumeration already finished. So, there is already a breaking change if users upgrade their .NET version to .NET 8. However, throwing an exception in this case seems to be the expected behaviour in general for Gremlin as that's what other GLVs do. I at least checked this for Java and Python. Java throws a NoSuchElementException and Python a StopIteration error. That is why I think that the correct thing for Gremlin.Net is to also throw an exception here as we should have consistent behaviour across GLVs. In that case, we should of course throw the exception here irrespective of the .NET version used. If we want to consistently throw an exception in .NET, then the question is when we want to make this change: In the next patch releases on 3.6 / 3.7 or wait until 3.8.0? I don't have a strong preference here but tend slightly towards adding the breaking change on 3.6/3.7 because I think that it's confusing for users to get different behaviour only by updating to .NET 8. If we make this change in the next release, then we at least have a consistent behaviour across GLVs and also across .NET versions. In general, users are only affected by this if they are relying on behaviour that has only been present in the .NET GLV. Any opinions on this? If there are no objections in the next 72 hours, then I'll assume lazy consensus in favour of a) letting Gremlin.Net throw an exception here (to be consistent with other GLVs) and b) introducing this change with the next 3.6/3.7 releases.
