Verify.sms usage question
Closed this issue · 2 comments
We're currently integrating TeleSign SDK into our project and testing various edge cases related to sms
After debugging and stepping through the code, it would appear that all IO exceptions are swallowed, and we get back a 'null' VerifyResponse object, at which point we're somewhat unsure what to do with it. We are unable to determine what went wrong and whether the request should be attempted again at some point in the future or not.
Could you give us some recommendations regarding this scenario, and how other clients are dealing with it ?
A good example of this case is when you cannot open a connection to rest.telesign.com (for whatever reason) - connection.getOutputStream() throws IOException, which gets swallowed and we get null back.
Ideally we would contribute to the project and try to always return a VerifyResponse instance, with appropriate error and/or status fields filled in, but since many clients have already integrated, this could be a dangerous way forward.
We could maybe add an optional vararg param to sms method - it would be an exception collector, so that exception(s) could be captured and analysed by client code later.
Let me know your thoughts.
@gibffe you raise a valid point. We actually have a long list of enhancements (corrections) we want to make to the Java SDK but have not done so since most would break existing clients. We just recently published the current version to Maven as v0.x.x. The plan is to bump the version to v1.x.x when we address these types of issues.
- Code should adhere to Java naming conventions.
- Internal exceptions should not be written to System.err.println. We should expose the exceptions as TeleSignException types.
- Better reuse of Responses classes.
- Better unit test that don't depend on customer keys and talking to the live service
- Proxy support.
- Add support for Maven.
- Add support for OSGi.
- Proper javadocs.
- Update GitHub documentation.
- ...
As far as error handling goes, most service based errors will respond with an errors array containing the error code with description. As you already noted if there is an unexpected error it will most likely mean a local issue (DNS resolution, Proxy, etc.) whereas the service will respond with a -90001 if it encounters an unexpected error.
http://docs.telesign.com/rest/content/xt/xt-error-codes.html
By the way appreciate the recent contributions and look forward to more. ;)
Sounds good, we're looking forward to 1.0 ! And don't mind me if I do contribute a bit more ;D