Couple of things here to look into. First, the call to getPost() will throw an Exception if the isAvailable() flag is false. And the first time this is called (for authentication purposes), this flag is not set. Right below this code that throws the exception, is a "checkAuthentication" call. So I am thinking that the initial call to check the flag and throw the MonitoringException can be removed.
Also - when the response comes back, it is possible to get exceptions from the json parser of the response (especially when API versions change). If this were to happen, it would not be an auth rejection. The code here probably needs to do more work to distinguish between "invalid credentials" (API is up and running and responded with an auth failure) and "other" errors - like for example the API not being available (web server stopped), or some kind of JSON parsing error (looking for a json element that may not be in the response due to an API change on the server side).
Couple of things here to look into. First, the call to getPost() will throw an Exception if the isAvailable() flag is false. And the first time this is called (for authentication purposes), this flag is not set. Right below this code that throws the exception, is a "checkAuthentication" call. So I am thinking that the initial call to check the flag and throw the MonitoringException can be removed.
Also - when the response comes back, it is possible to get exceptions from the json parser of the response (especially when API versions change). If this were to happen, it would not be an auth rejection. The code here probably needs to do more work to distinguish between "invalid credentials" (API is up and running and responded with an auth failure) and "other" errors - like for example the API not being available (web server stopped), or some kind of JSON parsing error (looking for a json element that may not be in the response due to an API change on the server side).