[
https://issues.apache.org/jira/browse/TINKERPOP-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419820#comment-17419820
]
ASF GitHub Bot commented on TINKERPOP-2616:
-------------------------------------------
divijvaidya commented on a change in pull request #1479:
URL: https://github.com/apache/tinkerpop/pull/1479#discussion_r715678825
##########
File path:
gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/Client.java
##########
@@ -124,8 +126,8 @@ public Client alias(final Map<String, String> aliases) {
public ResultSet submit(final Traversal traversal) {
try {
return submitAsync(traversal).get();
- } catch (UnsupportedOperationException uoe) {
- throw uoe;
+ } catch (RuntimeException re) {
Review comment:
Thank you for these changes.
1. The top level exception thrown back to the application has changed here
from `RuntimeException` to `NoHostAvailableException`. If a user has
application level code that is catching the `RuntimeException` and checking the
cause as `NoHostAvailableException`, that code will fail with client upgrade.
Hence, this is a backward incompatible change since it modifies the exception
contract.
For 3.4.x, could we please keep the contract as same (i.e. by wrapping
NoHostAvailableException in RuntimeException)?
2. All other changes in nested exceptions look good (we can still have
`NoHostAvailableException` with a nice cause).
3. I would vote that we can take this break in exception contract for 3.5.x
series since that is still going through some stabilization with respect to
other behaviours as well such as null semantics. @spmallette agree?
Overall, I think we do the following:
1. Merge this to master.
2. Create a different version with NoHostAvailableException as a 1st level
cause to merge into 3.4 branch.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Provide better exceptions with SSL related failures
> ---------------------------------------------------
>
> Key: TINKERPOP-2616
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2616
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Affects Versions: 3.4.12
> Reporter: Stephen Mallette
> Priority: Minor
>
> Propagate SSL exception to the client. Currently, if an error occurs during
> connection setup, client observes a generic “connection failed error”. This
> is because server has no mechanism to send an exact error to the client since
> the connection was never setup. The idea is to use WebSocket error codes to
> provide a more specific error to the client.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
