Requests that throw exceptions or fail should invoke their callback with an error state

[designzoo-peter]

This means the end user can at least know an error has failed. Currently there is no way to monitor the progress of a request, and if something goes wrong or an exception is thrown, the end user has no way of knowing that.

Is related to issues #108 and #110, but really applies across the board with all requests.

[karthiksaligrama]

I don't follow. you do get an exception object in the callback and when the callback is invoked you are required to check if the exception object is null. The exception object has the complete error state,including the error code and error message.

[PLockhart]

Strange, there must be a separate issue in itself then. From the issues I have created, when an exception has been thrown due to internet connection failure, the callback is never triggered. Have you tested the circumstance of no internet connection, rather than other exceptions that may be encountered along the way? If you follow the logic in the issues I have created (particularly #108) I don't see how the callback would ever be called in a lot of circumstances after an exception has been thrown. (I guess I'm just being very lucky in finding them)!

[karthiksaligrama]

No the sdk doesn't really check for internet connection. it just return what WWW gives the sdk which isn't much at this point. I can see how this would be useful. i will investigate if WWW can return some meaningful responses for client side connection issues.

To speak specifically about AmazonS3Client.PostObjectAsync in #108 is a special circumstance it doesn't follow the standard code path as in case of other API's. so its possible you find the issue there.

[karthiksaligrama]

Added feature request tag for checking network connectivity

[karthiksaligrama]

added this feature as a part of unityv3