fix: use resource type to identify type of error #57
Conversation
| } else if (message != null && DATABASE_NOT_FOUND_MSG_PATTERN.matcher(message).matches()) { | ||
| return new DatabaseNotFoundException(token, message, cause); | ||
| ResourceInfo resourceInfo = extractResourceInfo(cause); | ||
| if (resourceInfo != null) { |
There was a problem hiding this comment.
what about Instance Not Found ?
There was a problem hiding this comment.
The client library does not currently handle InstanceNotFound specifically, so it is currently not recognized as a separate error. I'll open a separate issue for it, as it could cause the same problems as DatabaseNotFound if someone deletes an instance while the client library has an active connection with a database on that instance.
|
May be worth considering, what if the resource info is not populated ?
What's the fallback in that case ?
…On Wed, Feb 5, 2020, 4:07 AM Knut Olav Løite ***@***.***> wrote:
Merged #57 <#57> into
master.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#57?email_source=notifications&email_token=AGX7VPCCXVOE3OB3YO5T4BLRBKTWHA5CNFSM4KPUK2PKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWNSO4AY#event-3009736195>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGX7VPBVC7DYY4E2MZ5ZR5DRBKTWHANCNFSM4KPUK2PA>
.
|
If the resource info is not populated, or it is populated with unknown values, the client library will automatically fall back to considering the error as a generic |
Use the returned resource type instead of the error message to determine the type of error.