Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify UnknownRemoteException message #659

Merged
merged 2 commits into from
Jun 23, 2021
Merged

Conversation

pkoenig10
Copy link
Member

Before this PR

The UnknownRemoteException error message can be misleading. Dialogue uses UnknownRemoteException for things other than just failing to deserialize a SerializableError.

After this PR

The UnknownRemoteException error message has been made a bit more generic to avoid being misleading.

@@ -42,14 +42,14 @@ public String getBody() {
}

public UnknownRemoteException(int status, String body) {
super(String.format("Error %s. (Failed to parse response body as SerializableError.)", status));
super(String.format("UnknownRemoteException: %s", status));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried to match the format of RemoteException and ServiceException.

@carterkozak
Copy link
Contributor

Dialogue uses UnknownRemoteException for things other than just failing to deserialize a SerializableError.

What are the other scenarios UnknownRemoteException is thrown?

@pkoenig10
Copy link
Member Author

@carterkozak
Copy link
Contributor

Makes sense, that case certainly cannot be parsed into a SerializableError, but the current message is confusing and makes it seem like something has gone wrong in an unexpected way. Lately we've seen proxies produce non-serializableerror non-2xx responses, and the wording makes folks thing there's a conjure client bug rather than a problem between services.

For the wording, I'm not sure it makes sense to duplicate the class name in the message, our stack traces already include class name. Perhaps something along the lines of Response status <CODE> to make it more obvious the number is a a response status?

@pkoenig10
Copy link
Member Author

pkoenig10 commented Jun 23, 2021

Lately we've seen proxies produce non-serializableerror non-2xx responses, and the wording makes folks thing there's a conjure client bug rather than a problem between services.

Yeah I've seen this also and is what I'm trying to mitigate with this PR.

Perhaps something along the lines of Response status <CODE> to make it more obvious the number is a a response status?

Sure that seems reasonable. I was only trying to be consistent with the other exception messages which have the form ClassName: <errorCode>.

@bulldozer-bot bulldozer-bot bot merged commit 438f81f into develop Jun 23, 2021
@bulldozer-bot bulldozer-bot bot deleted the pkoenig10/unknown branch June 23, 2021 03:26
@svc-autorelease
Copy link
Collaborator

Released 2.19.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants