Improve error handling

[CAATRV]

This python analytics library is pretty weak with regards to handling errors. Two examples: 1 - if the incorrect 'write key' is given to the analytics client, it will still go through the motions, and if you turn on analytics.debug, it will even report that the data (for example of a track() call) was successfully uploaded to Segment. This is terrible because Segment themselves tell you to use server-side calls if the data you are sending is mission critical. So as a dev, when using this library, be default you don't have a guarantee that your track() calls are delivered (imagine they are calls about purchases/revenue -- that's pretty important) - which might be okay if that was only the default, but that seems to be the only scenario. There is no way to reliably 'query' and therefore guarantee that track() calls have been delivered. I understand that Segment has coded for speed and throughput, but guaranteed message delivery can be more important in some scenarios. 2 - if there is a network timeout, after about 10 to 15 minutes a track call will still report success, but it obviously will not have been able to deliver the data to Segment. In the background, the library is trying to retry using 'requests' but when it finally gives up, it doe not raise an exception to the caller. So to the calling code, it seems like everything was okay. In summary, the library should allow the developer to set certain options that guarantee message delivery. For example, there could be an option created called: analytics.raise Then, the calling developer could do analytics.raise = True and write code that expects to know when events have not been delivered to the Source.

[nd4p90x]

@CAATRV I understand that it is frustrating that you cannot confirm that the server has received your calls, this is by design, there is no two-way communication between the client and server. The debugger is the only suggestion I can provide for you or anyone to verify that communication is occurring without error.

As for curl errors upon communicating, I would like to explore this further with you. I am not sure why you would not be seeing exceptions from the LIB when curl fails to communicate. There are curl error handlers within the LIB that should report what error occurred, if any.