[
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16380806#comment-16380806
]
Florian Hockmann commented on TINKERPOP-1906:
---------------------------------------------
Adding the status code as its own property is definitely a good idea. We could
also introduce dedicated Exception classes for some status codes where a
different error handling makes sense. The {{ServerTimeout}} status might be for
example a good candidate as that's also something where a retry can make sense.
When we keep the {{ResponseException}} as the base class for new exception
classes, then this wouldn't be a breaking change.
[~RomanKreisel]: Could you check which status code you get returned in that
case? It should be the beginning of the {{Message}} of the thrown
{{ResponseException}}.
If you want to look at the implementation of where the exception gets thrown:
* This is where the exception is thrown:
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatus.cs#L47]
* And this method shows the status codes that are treated as errors:
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/Messages/ResponseStatusCode.cs#L45]
The status codes themselves are explained here, as they aren't directly the
HTTP status codes:
[http://tinkerpop.apache.org/docs/3.3.1/dev/provider/#_graph_driver_provider_requirements]
Regarding the discussion on the mailing list about adding meta data: It might
be possible that that's also what they had in mind with the meta data, but I
think that we can already improve error handling in the driver just based on
the status codes that we already have.
> Make ResponseException explorable
> ---------------------------------
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.2.7
> Reporter: Roman Kreisel
> Priority: Major
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to
> react on the GremlinService's Response. The only content is the exception's
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode
> or anything else that's responded by the service.
>
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a
> "Request Rate to Large" response, in case you have high load on your
> database. In such a case, you want to be able to detect this "error" and just
> retry after a few milliseconds (i'm not sure, but i think even a proposal for
> this retry-timeout is given in the response)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
