- Unplugged network cable;
- Turned off wi-fi;
- Bad wi-fi signal strength;
- Bad network settings (e.g. DNS, gateway, etc.);
- Blocked by firewall;
- Problems on ISP's side (maintenance, etc.);
- Changed settings on your receiving side (e.g. you have closed account in your bug tracker);
- etc.
Well, we have several techniques for dealing with network delivery problems.
Setting up fallback send methods
First, you may set up multiple send methods. You arrange them in a preferred order:
Two send methods were set up
EurekaLog will try to send report via first defined send method - say, a bug tracker (FogBugz in the screenshot example above). If sending fails for whatever reason - EurekaLog will attempt to send via next available send method (SMTP client in the screenshot example above). And so on - until send succeeds or no more send methods are set up.
We usually recommend to use some bug tracker; followed by SMTP client; and Simple MAPI as last resort measure.
Saving bug report's backup
Second, if send fails (meaning all send methods) - EurekaLog may be set up to copy bug report file toMy Documents folder. See "Save bug report copy to My Documents folder" option. The user will be notified about it (assuming you have set up a failure message to be visible). The idea is that user can pick up this file and send it to you (developer) manually via any available means. You may change backup file location and/or file name by using OnCustomFileName event handler (you are interested in AFileType = ftZIPCopy).Additionally, report can be copied to the clipboard (both as file and as text simultaneously) - via "Copy bug report to clipboard" option. The idea is that user will be able to launch e-mail client (or go to support form on your web-site, etc.) and paste report into message.
Perform custom recovery
Finally, you may assign event handler to be called on send failure and perform you own custom actions (like saving bug report file to some sort of storage). For example, you may assignOnExceptionAction event handler and look for (AEurekaAction = atSent) and (AExecute = False). AAdditionalInfo will hold error message from sending. You may perform your recovery, and even switch AExecute to True to indicate successful send (so error message and creating backup will be skipped). If you did not alter "success" state of failed send - then OnExceptionError will be raised with AEurekaAction = stSent. You may perform your recovery there, and even swithc ARetry to True to retry sending.See also: How to get file name for bug report?
Automatic resending of failed bug reports
EurekaLog do not have such feature, because of many implementation issues.If send fails - EurekaLog can add report to some sort of offline storage. That is not an issue. Now, many questions arise:
- How should EurekaLog limit size of this storage?
- How often should EurekaLog clean it?
- What if application is uninstalled: who will clear the storage?
- How uninstaller will know about EurekaLog's storage location?
- Who and when will resend reports from storage?
- Should EurekaLog resend on application's startup?
- Should EurekaLog resend when another exception occur?
- What if application is non-GUI?
- What if startup time is important?
- What if next exception never occur?
- Should EurekaLog monitor network for availability?
- Use task scheduler?
- What if application is a DLL or COM object, e.g. it can not run by itself to resend reports?
There are too many questions without good answers. That is why this aspect is currently left for your own implementation. You may create a subfolder in
%APPDATA% folder; copy backups in that folder; resend when you can; may be create a standalone send application; clear subfolder when necessary.
