[
https://issues.apache.org/jira/browse/TINKERPOP-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089245#comment-18089245
]
ASF GitHub Bot commented on TINKERPOP-3238:
-------------------------------------------
spmallette opened a new pull request, #3460:
URL: https://github.com/apache/tinkerpop/pull/3460
The Java driver now throws a FailResponseException, a subclass of
ResponseException that implements Failure, when the server returns a
SERVER_ERROR_FAIL_STEP (595) status code. This makes remote handling of the
fail() step more consistent with embedded behavior.
Failure.format() is guarded against null traversal/traverser context since
that data is not transmitted from the server, preventing a NullPointerException
when formatting a remotely-reconstructed Failure.
Adds unit tests for both the defensive format() logic and the new exception,
plus documentation in the reference and upgrade guides.
@kenhuuu could you say what this change means in 4.0? I don't know that we
have the same kind of Exception hierarchy there anymore iirc
VOTE +1
> fail() improvements for remote applications
> --------------------------------------------
>
> Key: TINKERPOP-3238
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3238
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation, driver
> Affects Versions: 3.7.5
> Reporter: Stephen Mallette
> Priority: Major
>
> {{fail()}} step throws a {{FailException}} in embedded mode - it's documented
> as such. For remote with websockets you get a 595 error code but a
> {{FailException}} will not raise even for Java. For HTTP you get a regular
> old 500 exception with an error message that says the fail triggered. Clarify
> this situation in the documentation and consider an approach that can
> actually raise a {{FailException}} in java for the 595.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
