-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Proper handling of errors returned by telegram API #1446
base: dev
Are you sure you want to change the base?
Conversation
i haven't check code but seems like a nice addition, is there any way to see what's wrong with building? |
messageBuilder.append("code: ").append(response.code()); | ||
messageBuilder.append(", message: ").append(response.message()); | ||
|
||
if(response.body() != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you sure you can do it? shouldn't response.body() be called only once? multiple calls will cause an exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and all future or past calls too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just returns a value of the body
field
This if
just a check that body exists and accessing it will not give us an NPE
But the body
is a ResponseBody
instance and is consumable and should be consumed once
And here I call .string()
which consumes body and closes it, so this piece does not require try-with-resources
notation
@rubenlagus any chance to get it merged? |
Polling Bot
Errors from telegram were not logged properly - you never know what exacty telegram wants to tell you
All error details are added to the exception message which is always logged with the stacktrace
In Telegram Client HTTP error codes were not hadled at all -
onFailure
is only called on HTTP transport errors (cancellation, a connectivity problem or timeout), HTTP response coded should be handled inonResponse
We only knew about TG API errors by seend parsing exceptions, when error structure could not be pased as an expected java class
Now only 2xx responses are parsed normally, for other responses we gather details and throw an exception